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I.  INTRODUCTION 


Cyber  incident  response  encompasses  all  knowledge,  skills,  abilities  and  tools  that 
may  be  employed  to  detect,  analyze  and  recover  from  all  adverse  events  that  may  violate 
a  given  security  policy.  How  an  organization  cultivates  its  incident  response  directly 
correlates  with  its  overall  security  and  defense  against  potential  virtual  threats.  The 
practice  of  utilizing  virtual  machines  (VMs)  for  the  purpose  of  response  training  provides 
useful  hands-on  experience.  It  also  supports  each  student’s  ability  to  accurately  recognize 
prominent  artifacts  of  compromise. 

A.  WHAT  IS  CYBER  INCIDENT  RESPONSE? 

Cyber  incident  response  involves  numerous  phases  and  cannot  be  qualified  as  one 
specific  event  or  item.  Essentially,  cyber  incident  response  is  defined  as  the  process  of 
detecting  an  event  that  has  occurred  or  is  occurring  through  the  resolution  of  the  issue. 
The  process  itself  and  all  that  it  entails  is  incident  response.  Ideally,  an  organization 
would  have  durable  attack-and-exploit  prevention  measures  in  place  and  thus  be  resistant 
to  an  attack.  However,  with  techniques  and  motives  ever-changing,  it  is  not  realistic  to 
think  that  any  organization  is  immune  to  threat.  Therefore,  a  plan  of  action  for  incident 
response  is  necessary. 

1.  The  Defense  Continuum 

To  say  that  the  process  of  incident  response  is  cyclical  in  nature  is  an 
understatement.  It  (ideally)  begins  with  preparation,  but  it  does  not  end  with  lessons- 
leamed.  It  is  the  response  team’s  responsibility  to  make  the  most  of  those  lessons  and  to 
apply  them  toward  the  preparation  (cycle  completed)  of  future  incidents.  It  is  a  process  of 
constant  work  to  strive  for  improvement.  Continuous  effort  has  to  be  applied  to  not  only 
detect  and  eradicate  problems/attacks,  but  also  to  remain  steps  ahead  of  those  who  might 
want  to  cause  harm.  The  defense  continuum  essentially  includes  deterring,  preventing, 
detecting,  investigating  and  recovering  from  cyber  incidents.  Because  the  defense 
continuum  is  recurrent,  it  provides  steps  linking  the  process  and  thus  a  guide  for  carrying 
out  the  most  efficient  security  possible. 
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2.  Preparation 

An  excellent  place  to  start  when  attempting  to  build  an  incident  response 
capability  is  with  preparation — the  more  the  better.  Although  the  preparation  phase  of 
incident  response  falls  outside  the  scope  of  this  research,  it  is  valuable  to  discuss  it  here 
for  capturing  the  bigger  picture. 

Before  a  team  can  approach  an  organization  with  the  intent  of  minimizing  the  risk 
of  cyber  incidents,  they  must  first  ensure  their  own  readiness  to  respond.  Though  it  may 
seem  relatively  simple,  or  even  trite,  one  of  the  most  important  factors  of  preparation  is 
defining  the  mission  (Luttgens,  Mandia,  &  Pepe,  2014).  It  is  critical  to  have  a  well- 
developed  understanding  of  exactly  what  the  team’s  goal  is.  Defining  the  “goal”  is  an 
important  part  of  scoping  what  capabilities  are  required  of  an  incident  response  team. 
This  scoping  then  drives  the  pursuit  of  tools,  skills,  training,  team  membership, 
organization,  procedures,  etc.,  that  will  yield  an  effective  incident  response  team. 

Having  a  thorough  understanding  of  an  organization’s  policies  is  also  useful. 
Policies  are  typically  documents  that  establish  dicta,  or  precepts,  regarding  an 
organization’s  high-level  expectations  for  a  range  of  issues  that  contribute  to 
accomplishing  the  organization’s  mission.  Though  personnel  issues  (i.e.,  behavior, 
conflict  resolution,  grievances)  are  included  among  issues  addressed  by  policy,  we  are 
most  interested  in  policies  pertaining  to  cyber  security.  Because  incident  response 
services  are  often  provided  via  a  third-party  contractor,  it  is  necessary  that  such  external 
providers  understand  which  policies  may  inhibit,  or  even  prevent,  what  otherwise  may  be 
the  provider’s  “standard”  response  action. 

Another  significant  step  during  the  preparation  phase  is  establishing  reliable 
means  of  communication.  Both  internal  and  external  communication  must  be  taken  into 
account.  With  regard  to  internal  communication,  the  following  options  may  help  ensure 
the  integrity  and  confidentiality  of  potentially  sensitive  discussions  and  customer  data 
exchanges  (Luttgens  et  al.,  2014): 

•  Encrypt  emails 

•  Properly  label  all  documents  and  communications 
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•  Monitor  conference  call  participation 

•  Use  case  numbers  or  project  names  to  refer  to  an  investigation. 

A  team’s  need  for  appropriate  detection  and  attack- management  tools  is 
irrefutable. 


3.  Identification 

Once  an  organization  is  sufficiently  prepared  for  an  incident,  the  next  phase  is 
identification.  This  phase  has  two  responsibilities.  The  first  entails  detecting  (noticing) 
“questionable”  events.  The  second  entails  determining — via  appropriate  investigation — 
whether  a  given  cyber-related  event  (or  logically  related  collection  of  events)  constitutes 
an  incident  or  not.  This  is  especially  significant  because,  if  an  actual  (i.e.,  true-positive) 
incident  goes  undetected,  there  will  be  no  subsequent  call  for  any  containment  or 
eradication  action,  resulting  in  a  compromised  state  of  the  affected  cyber  system  for  an 
untold  amount  of  time.  Therefore,  this  initial  identification  of  an  incident  is  absolutely 
critical  for  the  Response  Team  to  make,  and  to  make  as  early  and  accurately  as  possible. 

As  it  pertains  to  detection  in  the  identification  phase,  Tondel,  Line  and  Jaatun 
(2014)  reference  a  study  in  which  incidents  were  detected  in  three  specific  ways: 

•  By  local  system  and  service  administrators  reporting  incidents  manually 
by  phone  or  email 

•  From  automatic  security  warnings  from  DFN-CERT  or  reports  from  other 
third  party  services 

•  Through  local  security  monitoring  mechanisms  (Tondel  et  al.,  2014). 

Local  detection  seems  to  be  one  of  the  most  significant  factors  in  reports  studied. 
Proximity  to  the  network  would  allow  for  more  prompt  detection  and  response.  In 
addition,  one  could  make  the  argument  that  a  thorough  examination  of  the  methods  and 
processing  of  the  detection  is  particularly  relevant.  This  is  because  a  critical  look  at  how 
identification  was  made  would  help  the  Incident  Response  Team  determine  whether  there 
was  a  false  positive  reported,  thereby  conserving  invaluable  time,  energy,  and  resources. 

Luttgens,  Pepe,  and  Mandia  (2014)  provide  a  generalized  checklist  to  take  into 


account  the  main  questions  the  members  of  an  incident  response  team  should  ask 
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themselves  upon  notification  of  detection.  These  questions  not  only  deal  with  how  an 
incident  is  detected,  but  with  the  detection  system  itself.  Things  like  whether  the 
detection  was  done  through  an  automated  or  manual  process;  the  sources  that  provided 
the  data;  if  the  source  data  was  validated  as  accurate;  if  the  source  data  was  preserved; 
and  the  detection  and  error  rates  all  must  be  taken  into  consideration  during  the  detection 
process.  What  leads  and  contributes  to  detection  is  just  as  important  and  relevant  as 
managing  that  which  may  come  from  it.  It  is  worth  noting  here  that  this  phase  will  be  a 
main  focus  for  the  purpose  of  this  research  as  the  training  provided  via  Virtual  Machines 
will  require  the  user  to  make  such  determinations. 

4.  Containment 

Once  an  incident  has  been  confirmed  to  have  occurred,  the  next  step  is  to  contain 
the  problem  and/or  problem  area.  Initially,  the  severity  of  the  attack  should  be  assessed  in 
order  to  effectively  determine  the  degree  of  the  response  and  resources  required  (Luttgens 
et  al„  2014). 

A  key  motive  during  the  Containment  Phase  is  to  ensure  that  the  attackers  are 
unaware  that  they  have  been  discovered.  There  are  many  reasons  for  this,  but,  essentially, 
the  main  purpose  is  to  avoid  evoking  a  reaction  from  the  attacker  (Luttgens  et  al.,  2014). 
Should  the  attackers  become  aware  that  they  have  been  discovered,  they  could  alter  their 
behavior  and  actions  in  such  a  way  that  would  make  it  difficult  for  investigators  to 
determine  the  breadth  of  damage  done,  thereby  also  impeding  the  eventual  eradication 
process. 

5.  Eradication 

Once  the  incident  has  been  contained  and  the  Team  has  been  able  to  establish  the 
degree  and  reach  of  the  attack,  the  process  of  eradication  begins. 

The  purpose  of  the  Eradication  Phase  is  to  completely  clean  the  affected  systems 
of  whatever  deleterious  incident  effects/artifices  have  been  “deposited”  on  those  systems 
(Luttgens  et  al.,  2014).  Such  effects/artifices  are  most  typically  one  of  either  a)  added  or 
modified  accounts,  or  b)  malware  residing  in  memory  and/or  storage  that  remains  active 
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or  under  future  actuation  control  of  a  remote  controller.  Eradication  needs  to  precede 
recovery  as  any  attempt  at  recovery  without  having  first  eradicated,  would  be  analogous 
to  painting  over  rust  to  protect  metal  from  further  oxidization  (Luttgens  et  al.,  2014).  The 
first  step  in  completing  this  task  is  to  develop  an  eradication  plan.  The  main  goal  of  this 
plan  is  to  remove  the  attacker’s  access  to,  and  presence  on,  the  system  entirely.  It  is 
important  to  note  that  this  plan  should  take  into  consideration  the  possibility  that  the 
attacker  may  try  to  regain  access  during  either  the  Eradication  or  Recovery  Phases 
(Luttgens  et  al.,  2014). 

There  are  two  issues  of  timing  that  are  essential  to  this  phase:  when  the 
eradication  is  to  take  place  and  how  long  it  will  last.  The  former  is  so  that  the  Team  can 
ensure  that  every  attacker  avenue  of  access  (vector)  has  been  thoroughly  considered  and 
mitigated/blocked.  The  latter  is  important  because  the  longer  the  phase  lasts,  the  more 
opportunity  the  attacker  has  to  reestablish  their  connection  elsewhere  in  the  system 
(Luttgens  et  al.,  2014). 

6.  Recovery 

The  Recovery  Phase  entails  bringing  any  affected  systems  back  into  operation 
and/or  back  online.  Affected  systems  should  be  properly  evaluated  to  ensure  that  they  are 
free  of  malicious  content,  fully  functional,  secure,  and  safe  for  use. 

At  the  end  of  the  Recovery  Phase,  the  entire  system  should  be  restored  and 
operate  in  such  a  way  as  to  have  the  appearance  that  there  was  never  any  hindrance  to 
begin  with. 

7.  Lessons  Learned 

Perhaps  one  of  the  most  important  phases  of  this  cycle  is  that  of  Lessons  Learned. 
While  proper  and  detailed  documentation  is  a  requirement  throughout  the  execution  of 
every  process  in  this  response  cycle,  it  is  here  especially  relevant. 

This  is  the  phase  in  which  all  incident-related  data  is  marshaled  and  assessed  for 
potential  application  going  forward.  A  review  of  the  security  controls  that  were  in  place 
at  the  time  the  attacker  gained  access  is  necessary  so  as  to  ascertain  what  preventive 
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controls  failed,  and/or  what  detection  controls  might  have  provided  earlier  detection.  It  is 
important  to  evaluate  both  what  worked  and  what  failed.  This  is  an  opportunity  to 
leverage  information  gained  from  the  most  recent  attack  response,  in  order  to  improve 
attack  prevention  and  response  going  forward. 

B.  IMPORTANCE  OF  CYBER  TECHNOLOGY  IN  THE  NAVY 

As  the  21st  century  dawned,  nearly  every  aspect  of  human  activity  had 
become  irrevocably  intertwined  with  cyber  space,  from  the  public  global 
Internet  and  its  newer  military  counterparts  to  GPS  precision  location, 
navigation,  and  timing  to  financial  transactions  and  personal 
communications  (Wilson,  2014,  pp.  8-9). 

The  advent  of  cyber  (i.e.,  computer-based)  technology  has  proven  to  be  quite 
beneficial;  it  allows  for — at  its  very  core — people  to  complete  tasks  in  seconds  that  once 
may  have  taken  days.  Due  to  this  convenience  and  potential  for  great  use,  the  Navy’s 
reliance  upon  technology  has  paralleled  that  of  its  civilian  counterpart.  However,  the 
potential  down-side  to  this  is  an  entrenched  “dependency”  that  creates  a  distinct  and 
relatively  new  kind  of  vulnerability:  a  heavily  automated  system-of-systems  that  presents 
a  large  target  surface  area  to  the  cyber-savvy  enemy.  It  is  this  high  dependency  on 
systems  with  numerous  vulnerabilities  that  militates  for  the  Navy  to  pursue  ever- 
improving  risk  management  capabilities.  An  excellent  way  to  illustrate  this  is  to  examine 
changes  over  time  and  how  the  Navy  has  adapted  accordingly. 

1.  Historical  Examples 

“Computers”  first  debuted  their  capability  during  WWII  as  establishing  their 
ability  to  crack  codes.  “Magic”  allowed  U.S.  forces  to  decipher  Japanese  codes  in  an 
arena  in  which  Allies  had  to  sometimes  interact  with  Axis  parties  out  of  material 
necessity  (Arquilla,  2011).  “The  age  of  computers  in  battle  that  has  unfolded  in  the  past 
70  years  has  proved  similar  to  earlier  eras  in  military  history,  with  these  new 
informational  tools  pointing  to  new  practices”  (Arquilla,  2011,  p.  59). 

As  technology  changes,  the  Navy  should  be  quick  and  adept  at  accepting, 
adapting  to,  and  mastering  its  ability  to  operate  new  technologies  in  a  manner  that 
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maintains  or  improves  its  tactical  advantage  in  combat.  The  cyber  environment  is  just  the 

newest  and  most  fertile  new  technological  change  to  expand  upon  in  that  regard. 

Fortunately,  it  is  apparent  that  the  significance  of  cyber  activities  has  come  to  the 

forefront  of  discussion.  The  Navy,  specifically  in  recent  years,  has  shown  great  strides  in 

its  overall  awareness  of  the  need  for  skilled  technicians  in  this  area.  This  can  be 

evidenced  in  the  U.S.  Navy  Information  Dominance  Roadmap — 2013-2028  and  the 

creation  of  the  Task  Force  Cyber  Awakening  (TFCA)  (Wilson,  2014). 

Matthew  H.  Swartz,  director  of  Communications  and  Networks  Division 

(N2/N6F1)  and  TFCA  lead  spoke  to  a  roundtable  in  October  of  2014  and  stated  this: 

In  the  last  decade,  DOD — and  specifically  the  Navy — has  been  forced  to 
reassess  our  risk  calculus  for  cyber,  to  understand  from  a  risk  perspective 
what  we  need  to  do  to  address  this  growing  area.  Because  of  that,  we  had 
to  make  sure  we  understood  the  risks  of  cyber  as  we  move  forward 
(Wilson,  2014,  p.  7). 

This  statement  not  only  reflects  the  awareness  for  the  need  to  definitively  and 
actively  research  the  future  of  the  cyber  arena,  but  also  the  urgency  to  explore  the 
potential  weaknesses  within  current  practice  and  policy.  It  also  highlights  the  uncertainty 
involved  in  making  a  conclusive  statement  regarding  what  “cyber”  actually  encompasses. 

The  fact  is  that  the  amount  of  cyber  threats,  attacks,  and  espionage  that  have 
transpired  within  the  last  decade  have  pushed  the  Navy  into  amending  its  approach  to  the 
cyber  environment. 

In  2007,  there  were  numerous  distributed  denial  of  service  (DDoS)  attacks  was 

perpetrated  against  Estonia.  Estonia’s  government  and  private-sector  information 

technology  infrastructures  were  put  at  risk.  Russia  was  first  thought  to  be  behind  the 

attacks.  This  was  because  the  attacks  appeared  to  have  come  from  servers  located  in 

Russia.  However,  because  of  the  anonymity  afforded  to  some  hackers,  it  was  later 

determined  that  “zombie  computers”  could  have  been  used  and  taken  control  of  by 

anyone.  Even  Estonians  themselves  could  have  been  the  perpetrators  in  an  attempt  to 

reinforce  anti-Russian  feelings.  No  retaliation  occurred  (Guinchard,  2011). 

Canada  is  another  nation  that  has  been  struck  by  cyber  attacks.  The  Treasury 

Board,  the  Finance  Department  and  Defense  Research  and  Development  Canada  were  the 

victims.  The  impact  lasted  for  approximately  two  months.  The  thought  at  the  time  was 
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that  the  hackers  were  attempting  to  gain  advance  knowledge  of  the  federal  budget.  Their 
proposed  national  budget  maintains  confidentiality  due  to  the  fact  that  once  it  is 
submitted  to  Parliament,  changes  cannot  be  made.  This  is  thought  to  be  the  purpose  of  the 
attack.  Advance  knowledge  of  the  federal  budget  can  be  used  for  personal  financial  gain. 
Unfortunately,  it  is  practically  impossible  to  officially  determine  the  target  of  or  reason 
for  the  attack  because  whoever  perpetrated  the  attack  was  ultimately  never  discovered. 
Though  the  attack  was  traced  to  China’s  servers,  China  may  have  not  been  the  culprit  of 
the  attack.  Someone  else  could  have  chosen  China  to  be  the  smoke  screen  for  the  attack 
to  help  achieve  anonymity,  or  perhaps  to  misplace  blame,  or  to  otherwise  confound  the 
incident  investigators  (Pfleeger  &  Pfleeger,  2012). 

There  were  two  main  components  to  the  attack  perpetrated  against  Canada.  First 
“executive  spear  phishing”  was  used  to  take  over  the  computers  of  senior  officials.  Once 
this  was  completed,  messages  were  sent  to  their  internal  Information  Technology 
department  from  individuals  posing  as  the  officials.  The  purpose  of  this  was  to  gain 
access  of  passwords  for  key  systems.  “The  second  component  was  lacing  PDF  files  with 
hidden  programs  and  forwarding  them  to  others  in  the  above  departments”  (Van  Dusen, 
2013,  p.  5).  The  perpetrators  were  again  relying  upon  impersonation  of  the  officials  who 
owned  the  email  accounts  to  convince  the  recipients  of  their  legitimacy.  Upon  opening 
the  PDFs,  the  malicious  programs  began  to  execute  and  simultaneously  route  confidential 
and  private  information  back  to  the  attackers  (Pfleeger  &  Pfleeger,  2012). 

The  Stuxnet  worm  used  in  2010  is  also  an  example  of  the  effective  use  of  a  cyber 
attack.  This  worm  was  used  against  nuclear  facilities  in  Iran.  Stuxnet  had  two  main 
purposes.  One  function  was  to  “force  Iran’s  centrifuges  to  spin  out  of  control”  (Gervais, 
2012,  p.  37).  The  other  goal  for  Stuxnet  was  to  simultaneously  convince  operators  that 
the  centrifuges  were  functioning  as  though  nothing  was  wrong  (Van  Dusen,  2013). 
Stuxnet  was  also  designed  to  upload  information  about  the  system  it  infected,  which 
effectively  made  it  not  only  a  denial  of  service  cyber  weapon,  but  also  a  reconnaissance 
(information  gathering)  tool  for  additional  attacks  (Gervais,  2012).  This  attack  reportedly 
set  back  Iran’s  their  nuclear  program  by  a  minimum  of  two  years  (Slocombe,  2012).  Iran 
chose  to  retaliate  in  the  summer  of  2011.  That  attack,  directed  in  part  against  the 
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Netherlands,  was  so  massive  that  it  “led  the  Dutch  Justice  Minister  to  warn  the  only 
secure  way  to  communicate  with  the  Dutch  government  at  that  time  was  with  pen,  paper, 
or  fax”  (Slocombe,  2012,  p.  38). 

More  recently,  in  2013,  a  cyber  intrusion  was  experienced  from  the  United  States 
Army  Corps  of  Engineers  National  Inventory  of  Dams.  The  database  that  this  system 
encompasses  is  around  8,100  major  dams  in  the  United  States.  The  infiltration  of  such  a 
system  has  numerous  potential  ramifications  (Wilson,  2014). 

2.  Cyberspace  Damage  Control 

The  question  becomes,  now  that  the  Navy  has  acknowledged  the  cyber 
environment  as  a  place  for  further  cultivation,  exploration,  and  investment,  what  can  be 
done  to  diminish  the  likelihood  that  our  cyber  vulnerabilities  will  be  exploited?  The 
answer  is  simple:  preparedness.  The  key  to  getting  ahead  of  adversaries  is  to  be  aware 
that  they  are  coming,  to  be  aware  of  the  attacks/exploits  they  are  bringing  with  them,  and 
to  be  cognizant  of  the  tactics  they  are  likely  to. 

Cyberspace  has  been  widely  accepted  as  the  fifth  domain  of  warfare  (1-Sea,  2- 
Air,  3-Land,  4-Space,  and  5-Cyberspace).  Eom,  Kim,  Kim,  and  Chung  (2012)  make  the 
argument  for  the  need  for  cyber  superiority  as  well  as  for  the  development  of  a  “cyber 
warrior.”  They  contend  that  the  cyber  warrior  should  have  thorough  knowledge  of 
military  policies,  cyber  strategy,  cyber  tactics,  cyber  operations,  cyber  intelligence 
collection,  as  well  as  cyber  attack  and  cyber  defense  technology.  The  concept  of  having  a 
distinct  and  separate  force  dedicated  to  strictly  understanding  and  operating  within  the 
cyber  realm  is  not  only  interesting,  but  a  practical  way  of  mitigating  the  risk  of  attack  on 
our  systems  while  also  improving  our  ability  to  efficiently  attack  the  systems  of  our 
adversaries. 

This  movement  also  elevated  information  technology  (IT)  from  the  “nerd” 

department  responsible  for  keeping  an  organization’s  phones  and 

computers  working  to  the  heart  of  secure  data  and  networking  (Wilson, 

2014,  p.  3). 

Not  only  should  all  military  personnel  have  a  basic  comprehension  of  proper 
cyber  use  policies,  there  should  also  be  a  concentration  of  individuals  with  a  background 
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in  cyber  warfare  specifically.  This  is  the  only  way  to  truly  defend  against  threats  while 
also  being  capable  of  perpetrating  such  threats  against  our  (U.S.)  adversaries  when  it  is 
militarily  prudent  to  do  so. 

C.  TRAINING  DIFFICULTIES 

1.  Labs  and  Fleet-Wide  Scalability 

The  Naval  Postgraduate  School  (NPS)  has  a  Cyber  Battle  Lab  (CYBL).  A  cyber 
battle  lab  “offers  state  of  the  art  network  and  computer  systems  to  build  large  scale 
computer  networks  and  computing  environments  for  experimentation”  (Terry  et  al.,  2014, 
p.  1).  The  CYBL  is  disconnected  from  the  school’s  internal  network  (intranet)  to  allow 
red  team  operators  to  attack  blue  team  operators  and  to  practice  using  a  wide  variety  of 
tools  for  offense  and  defense  without  the  fear  of  hurting  the  school’s  local  area  network 
(NPS,  2015).  This  type  of  lab  allows  students  to  connect  to  the  virtual  environment 
provided  by  the  cyber  battle  lab,  from  anywhere  in  the  world.  This  type  of  environment  is 
excellent  for  teaching  the  next  generation  of  incident  handlers  how  to  detect  various  types 
of  attacks  that  can  happen  on  a  network,  and  to  mitigate  or  eradicate  such  threats  as  they 
are  discovered.  There  are  only  so  many  workstations  that  can  be  logged  into  the  lab  at 
any  given  time.  Though  it  would  be  ideal  for  every  network  defender  in  the  fleet  to  have 
access  to  a  cyber  lab,  it  is  just  not  possible.  A  cyber  battle  lab  is  better  suited  for  “A” 
schools,  “C”  schools  and  universities.  Sailors  in  the  fleet  need  a  way  to  practice  using 
various  tools  to  detect  and  respond  to  real  world  attacks  without  necessitating  access  to  a 
high-tech  cyber  battle  lab. 

2.  Threat  and  Vulnerability  Selection 

The  list  of  threats  and  vulnerabilities  that  exist  in  the  world  of  cyber  defense  is 

forever  changing  and  growing.  This  can  be  overwhelming  for  many  to  even  think  about. 

The  important  aspect  of  cyberattack  detection  is  to  know  what  normal  behavior  looks  like 

on  any  given  network.  It  is  impossible  to  know  every  attack  and  vulnerability  that  exists, 

but  practicing  with  various  tools  can  help  an  incident  responder  detect  when  something  is 

not  quite  right,  and  then  respond  to  it.  The  Navy  mostly  utilizes  Windows  operating 

systems  (OS).  In  order  to  develop  adequate  lab  scenarios  for  incident  responders  to 
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properly  detect  and  respond  to  potential  incidents,  we  should  look  at  the  areas  that  are 
most  likely  to  be  attacked,  and  where  an  attacker  can  cause  the  most  damage. 

There  are  numerous  different  areas  that  can  be  attacked  on  a  Windows  OS.  It  is 
prudent  then,  given  the  limited  training  time  available,  to  focus  on  high-occurrence 
and/or  high-impact  WinOS-based  attacks.  Particular  areas  of  interest  are  NTFS  and  file 
system  analysis,  Windows  prefetch,  event  logs,  scheduled  tasks,  the  Registry,  memory 
forensics  and  alternative  persistence  mechanisms  (Luttgens  et  al.,  2014). 

D.  HOW  TO  MITIGATE  THESE  CHALLENGES 

Not  all  sailors  have  access  to  a  CYBL.  For  those  who  do  not,  it  is  important  to 
configure  a  way  for  them  to  receive  necessary  incident  response  training.  This  will  ensure 
that  they  will  be  able  to  perform  their  duties  regarding  cyber  security  efficiently, 
regardless  of  circumstance  or  location.  The  use  of  VM  is  a  perfect  aid.  By  creating  and 
providing  scenarios  directed  toward  detecting,  resolving,  and  recovering  from  threats  in  a 
VM  environment,  we  are  able  to  provide  a  hands-on  experience  to  those  who  may  not 
otherwise  have  the  opportunity  to  engage  safely  and  constructively  with  these  situations. 
We  have  created  seven  scenarios  via  VM  use  that  will  enable  the  operator  to  experience 
and  experiment  with  different  types  of  threats  and  how  to  deal  with  them. 

The  benefits  of  using  a  VM  for  educational  purposes  may  not  be  readily  apparent. 
However,  further  discussion  will  show  its  worth  for  exactly  this  purpose.  A  VM  is 
delivered  simplistically;  easily  reverted  to  a  normative  state;  and  functions  without 
inflicting  harm  on  the  physical  machine.  In  addition,  use  of  a  VM  allows  for  the 
instructor  to  focus  the  training  to  items  that  tend  to  require  more  need  for  investigation. 
Things  like  the  Registry,  processes,  tasks,  accounts,  etc.,  are  all  among  the  items  that  are 
most  likely  to  show  that  an  incident  has  occurred.  Network  services  also  possess  specific 
items  of  interest  that  should  catch  a  user’s  attention. 

The  use  of  VM  also  allows  the  instructor  to  highlight  the  best  incident 
investigative  tools.  This  allows  the  user  to  become  more  comfortable  with  not  only  what 
to  look  for,  but  what  they  will  need  to  utilize  to  identify  and  remedy  a  threat  or  attack. 
Tools  like  the  QuickChecksum  Verifier,  PEView,  TCP  and  Regshot  may  be  common,  yet 
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are  advantageous  for  the  user  to  be  well  versed  in  their  use.  Having  a  firm  understanding 
of  the  command  line  and  all  that  can  be  gleaned  from  it  is  also  beneficial.  Because  the 
command  line  is  built  into  every  Windows  operating  system,  it  is  evident  that  a  user 
should  become  quite  familiar  with  it.  NETSTAT,  viewing  events,  and  system  file 
integrity  are  all  tools  that  provide  a  starting  point  for  investigation. 

The  Navy  should  consider  having  an  IT  incident  response  team  at  every  command 
that  is  trained  exclusively  to  handle  cyber  incidents.  They  should  be  required  to  conduct 
incident  response  training  through  VM  to  keep  their  skills  sharp  and  at  the  same  time, 
learning  how  to  properly  respond  to  new  threats  that  emerge.  The  Navy  severely  lacks 
adequate  training  and  organization  as  it  pertains  to  incident  response.  If  cyberspace  is  the 
new  domain  of  warfare,  we  must  assume  that  our  networks  are  already  infiltrated.  Our 
Navy’s  Information  System  Technicians  should  and  must  be  more  focused  on  the  security 
of  our  information  systems  than  just  fixing  hardware  and  software  issues.  This  research 
demonstrates  a  convenient  way  to  accomplish  this  training  regardless  of  a  sailor’s 
location. 
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II.  THE  MERITS  OF  VIRTUAL  MACHINES  FOR  INCIDENT 

RESPONSE  EDUCATION 


The  benefits  of  using  virtual  machines  for  the  purpose  of  incident  response 
education  are  many.  Providing  students  with  the  opportunity  to  interact  with  a 
threat/attack  that  has  been  pre-captured  in  a  virtual  machine  (VM)  gives  the  student  the 
chance  to  experiment  with  the  information  learned  and  apply  what  they  have  learned  in  a 
controlled  setting.  In  addition,  the  teacher  has  the  ability  to  view,  analyze,  and  respond  to 
the  students’  reaction  to  the  variables  offered  by  each  scenario. 

A.  THE  VM  CONCEPT 

Virtualization  refers  to  a  concept  in  which  access  to  a  single  underlying 
piece  of  hardware,  like  a  server,  is  coordinated  so  that  multiple  guest 
operating  systems  can  share  that  single  piece  of  hardware,  with  no  guest 
operating  system  being  aware  that  it  is  actually  sharing  anything  at  all.  A 
guest  operating  system  appears  to  the  applications  running  on  it  as  a 
complete  operating  system  (OS),  and  the  guest  OS  itself  is  completely 
unaware  that  it’s  running  on  top  of  a  layer  of  virtualization  software  rather 
than  directly  on  the  physical  hardware  (Golden,  2008,  p.  10). 

Essentially,  a  virtual  machine  operates  on  top  of  the  actual  machine  and  can  be 
configured  to  run  a  variety  of  operating  systems.  There  is  a  plethora  of  benefits  to 
utilizing  such  an  architecture  for  the  purpose  of  incident  response  testing.  These  are 
highlighted  in  the  sections  that  follow. 

B.  SELF-CONTAINED  AND  PORTABLE 

When  computers  were  first  created,  their  true  capacity  and  potential  was  likely 
unforeseen  at  the  time.  However,  the  leaps  and  bounds  technology  has  made  since  the 
first  computers’  inception  are  undeniable.  The  advent  of  laptops  and  smart  phones  meant 
we  were  able  to  complete  our  computing  needs  on  the  go.  This  characteristic 
revolutionized  how  we  are  able  to  get  things  done,  as  sometimes  it  is  simply  not  feasible 
to  be  physically  present  at  a  certain  location  with  so  many  responsibilities  drawing  our 
attentions  away. 
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The  same  concept  is  applied  to  the  use  of  virtual  machines.  Students  will  be  able 
to  work  on  and  with  their  attack  detection  and  response  skills  anywhere,  as  their  virtual 
machines  can  be  delivered  via  drop  box  or  flash  drive  and  run  on  top  of  VM-compatible 
laptops.  Users  can  also  save,  copy,  and  move  their  environment  from  machine  to 
machine.  Michael  Price  (2008)  discusses  the  benefits  of  copying  a  VM  and  files  to  a  flash 
drive  and  taking  it  “with  you  wherever  you  go.”  Because  the  educational  environment 
may  extend  across  location — as  in  the  instance  when  a  student  is  underway — and  may 
not  have  access  to  server-based  VMs,  this  is  extremely  useful.  The  instructor  has  the 
ability  to  set  a  return  time  for  when  a  particular  lesson  may  be  handed  in.  Upon  doing  so, 
the  instructor  then  may  inspect  what  has  or  has  not  been  completed.  In  addition,  a  report 
may  accompany  the  work  completed,  and  what  attempts  were  made  can  be  documented 
by  the  student  for  the  instructor’s  evaluation. 

C.  EASILY  RECOVERABLE 

As  is  the  case  when  any  novice  is  learning  and  practicing  new  skills,  there  is  a 
chance  for  something  to  go  wrong.  One  educational  advantage  of  using  virtual  machines 
is  that  students  can  gain  hands-on  experience  with  actual  attacks  in  a  controlled  setting. 
However,  mistakes  can  happen,  making  it  all  the  more  necessary  to  have  precautions  in 
place  to  ensure  that  any  issue  can  be  readily  corrected  so  work  may  resume. 

One  of  the  best  educational  outcomes  of  using  Virtual  Machines  is  that  they  can 
be  promptly  reconfigured  to  a  previous — good — state!  So,  if  a  student  compromises  his 
VM  during  training,  he  would  be  able  to  revert  or  renew  his  VM  to  its  previously  non- 
compromised  state  and  continue  working.  Because  the  virtual  machine  and  physical  host 
practically  exist  independently,  no  damage  is  suffered  by  the  host  OS  or  physical 
machine.  The  VM  configuration  is  simply  a  set  of  parameters  backed  up  by  the  Snapshot 
Function. 

D.  INCIDENT  RESPONSE  TRAINING  UTILIZING  VMWARE 

Incident  responders  throughout  the  Navy  do  not  all  have  access  to  cyber  battle 

labs.  There  is  however,  an  alternative  that  can  be  effective.  VMWare  software  can  be 

downloaded  from  the  VMware  website  that  can  install  a  virtual  machine  on  just  about 
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any  workstation  (i.e.,  any  host  OS).  After  this  software  is  downloaded,  an  OS  of  the  users 
choosing  can  also  be  downloaded  to  run  on  “top  of’  the  host  OS  (the  guest  OS).  The 
Navy  could  utilize  Navy  Knowledge  Online  (NKO)  to  provide  various  attacks  that  can  be 
downloaded  onto  Virtual  Machines  from  NKO  that  are  placed  securely  on  the  website  by 
a  trained  IT  professional.  This  would  allow  the  command’s  incident  response  plan  to  be 
practiced  in  real  time,  from  the  Identification  to  the  Lessons  Learned  phases.  Having  this 
capability  would  give  the  network  defenders  the  chance  to  look  at  attacks  at  their  leisure, 
when  new  tools  hit  the  market,  new  attacks  are  placed  on  NKO,  or  when  tasked  to 
practice/train  by  their  chain  of  command. 
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III.  PROMINENT  ARTIFACTS  FOR  INDICATORS 
OF  COMPROMISE 


Arguably,  one  of  the  most  difficult  aspects  of  incident  response  is  the  ability  to 
narrow  down  specific  factors  of  the  incident  itself.  Locating  and  fixing  the  problem 
area(s)  is  ultimately  the  point  of  incident  response.  Therefore,  understanding  what  the 
common  artifacts  are  that  typically  indicate  an  attack  or  a  place  of  compromise — as  well 
as  where  to  look  for  them — is  paramount.  These  items  can  be  considered  and  either 
dismissed  as  irrelevant,  or  further  researched  to  provide  direct  answers  or  suggest  leads 
for  further  investigation.  A  superb  foundation  and  place  to  start  can  be  established  by 
examining  the  things  that  are  typically  good  indicators  of  exploitation. 

A.  WINDOWS  OPERATING  SYSTEM 

The  Windows  Operating  System  was  chosen  for  the  purpose  of  this  project  due  to 
its  pervasiveness  throughout  the  United  States  Navy.  Because  the  majority  of  the 
computers  utilized  by  the  Navy  function  with  this  system,  it  was  evident  that  further 
analysis  and  research  into  its  architecture  and  defense  should  be  the  primary  focus.  Thus, 
below  are  enumerated  the  primary  components  of  the  Windows  Operating  System  that 
are  of  most  utility  as  indicators  of  compromise  (IOC). 

1.  Registry 

The  Registry  is  considered  central  to  the  Windows  Operating  System  (WOS).  It, 
in  and  of  itself,  is  the  foundation  for  much  of  the  information  available  from  the  system. 
The  Registry  is  the  “primary  database  of  configuration  data”  and  the  amount  of  data  that 
can  be  gleaned  from  it  is  extensive.  In  addition,  as  the  system  itself  developed  in 
complexity,  so  too  has  the  amount  of  intelligence  that  can  be  tracked — and  potentially 
manipulated  within  the  Registry  (Luttgens  et  al.,  2014). 

The  Registry  is  organized  into  two  different  types  of  hives:  system  and  user- 

specific.  User-specific  Registry  hives  can  be  found  within  each  user’s  profile  directory. 

Hives  are  generally  stored  in  a  single  file  on  a  disk.  They  are  not  human  readable  but  can 

be  parsed  using  many  different  tools.  However,  one  cannot  copy  hive  files  with  Windows 
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Explorer.  Instead  a  forensic  imaging  or  some  sort  of  acquisition  tool  to  copy  them  is 
required.  There  are  five  central  Registry  hives  in  the  path: 

%SYSTEMROOT%\system32\config:  SYSTEM,  SECURITY,  SOFTWARE, 

SAM,  and  DEFAULT. 

These  are  hive  file  names  with  no  extension  (Luttgens  et  al.,  2014). 

Registry  data  is  stored  within  a  tree  formation  and  is  comprised  of  three  items: 
keys,  values,  and  data  (Luttgens  et  al.,  2014).  The  layout  of  this  information  can  be 
viewed  within  the  Windows  native  Registry  editor  (regedit.exe).  The  key  represents  a 
path,  the  value  is  similar  to  the  naming  of  a  file  and  the  data  reflects  the  true  information 
contained  therein.  The  amount  of  information  that  can  be  monitored,  gathered,  and 
maliciously  altered  within  this  framework  is  enormous.  There  are  numerous  encodings  in 
which  Registry  data  is  stored,  and  it  is  because  of  this  that  Registry  values  are  human 
readable  whereas  other  items  are  not.  Per  Luttgens  et  al.  (2014),  the  main  rootkit 
registries  are  as  follows: 

•  HKEY_LOCAL_MACHINE  (aka  HKLM) 

•  HKEY_USERS  (aka  HKU) 

•  HKEY_CURRENT_USER  (aka  HKCU) 

•  HKEY_CURRENT_CONFIG  (aka  HKCC) 

•  HKEY_CLASSES_ROOT. 

Registry  keys  contain  a  single  timestamp.  They  have  an  associated 
LastWriteTime  set  when  the  key  is  created.  The  timestamp  is  also  updated  whenever  any 
values  under  the  keys  are  changed.  However,  changes  to  subkey  values  do  not  impact  the 
parent  key’s  timestamp.  In  addition,  Registry  timestamps  are  only  affiliated  with  keys 
and  not  values  or  data  therein.  Timestamps  are  helpful  in  that,  by  using  file  system 
metadata  and  other  evidence  that  a  key  was  changed  during  a  period  of  known  hacker 
activity,  one  could  assume  the  change  was  made  by  an  unauthorized  party. 

There  are  limitations  of  using  a  timestamp  of  a  Registry  key.  If  there  are  a 
significant  number  of  other  keys — particularly  within  the  same  or  nested  paths — updated 
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within  the  same  second  or  minute,  it  is  probable  that  there  has  been  a  legitimate  change 
brought  about  by  the  operating  system,  software  update,  or  even  a  security  application 
such  as  an  antivirus  program  (Luttgens  et  al.,  2014). 

Because  the  nature  of  the  Registry  is  that  it  is  the  foundation  of  the  Windows 
Operating  System,  the  amount  of  evidence  that  can  be  attained  is  vast.  However,  Luttgens 
et  al.  (2014)  provide  a  consolidated  list  of  keys  and  values  they  found  to  be  of  high 
significance  in  their  experience  with  incident  response:  System  Configuration  Registry 
Keys,  Shim  Cache,  Common  Auto-Run  Registry  Keys,  and  User  Hive  Registry  Keys. 

2.  Processes 

A  process  is  essentially  a  series  of  actions  taken  to  reach  a  desired  endpoint/goal. 
In  computing  terms,  a  process  refers  to  an  instance  of  a  program  that  is  being  executed.  In 
order  to  accomplish  anything  on  an  operating  system,  a  process  must  be  run  (Luttgens  et 
al.,  2014). 

Per  Regalado,  Harris,  and  Harper  (2015),  an  important  action  that  needs  to 
transpire  regarding  processes  is  that  of  monitoring.  Process  Monitor,  as  its  name  implies, 
is  a  process  monitoring  tool  for  Windows  that  provides  a  real-time  view  of  the  file, 
system,  Registry,  and  process/thread  activity.  A  useful  feature  of  this  monitor  is  that  it 
allows  for  the  customization  of  the  filter  so  the  user  is  able  to  adjust  what  they  are 
looking  at  and  searching  for.  This  way,  the  operator  is  able  to  focus  on  the  data  he/she  is 
most  interested  in  and  not  be  completely  overwhelmed  with  information. 

3.  Files  of  Interest 

Because  there  is  a  plethora  of  ways  in  which  a  hacker  may  exploit  a  targeted 
computer,  it  is  important  to  be  able  to  have  a  method  for  sorting  through  all  of  the 
information  available.  Files  that  are  inexplicably  altered  are  considered  to  be  “files  of 
interest.”  These  alterations  can  be  anything  from  an  atypical  file  name,  to  an  incorrect 
hash,  or  an  improper  location  in  the  file  system  (Luttgens  et  al.,  2014).  In  addition, 
examining  first,  those  files  that  have  historically  been  specifically  targeted  is  also 
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preferable  from  a  finding  the  “signal  among  the  noise”  investigative  perspective 
(Luttgens  et  al.,  2014). 

An  excellent  example  of  this  are  auto-run  keys.  These  keys  are  intended  to  allow 
for  Windows  executable  files,  Dynamic  Link  Libraries  (DLLs),  and  other  components  to 
load  upon  system  boot,  user  login,  and  other  conditions.  Because  these  keys  are  executed 
during  the  boot  and/or  user  login  procedure,  and  are  by  design  intended  to  operate 
transparently,  these  auto-run  keys  tend  to  be  a  favorite  attack  target  for  hackers. 
Fortunately,  there  are  analytical  techniques  that  can  be  applied  to  any  type  of  Registry- 
based  auto-run.  Using  these  types  of  techniques  can  aid  in  narrowing  down  what  data 
requires  further  examination. 

Jason  Luttgens,  Kevin  Mandia,  and  Matthew  Pepe  (2014)  discuss  the  tendency  of 
some  incident  response  personnel  to  attempt  to  “eyeball”  malicious  auto-runs.  They 
advocate  against  this  because  they  consider  it  easy  to  make  a  mistake  via  this  method. 
They  demonstrate  this  by  listing  four  keys  with  a  ServiceName,  Description  and 
ImagePath  for  each.  They  indicate  that  one  of  these  is  malicious  and  pose  the  question 
asking  if  the  reader  is  able  to  identify  the  “bad  one.”  The  three  that  were  legitimate  keys 
had  issues  that  would  seemingly  be  cause  for  concern.  These  “anomalies”  included 
spelling  errors,  lack  of  a  description,  the  directory  from  which  one  is  run,  and  a 
punctuation  error.  However,  the  keys  with  these  attributes  were  all  deemed  to  be 
legitimate.  The  key  that  was  malicious  was  so  because  “an  attacker  had  modified  the 
ServiceDll  to  point  to  a  malicious  file,  iprinp32.dll,  rather  than  the  correct  DLL  file  name, 
iprip.dll”  (2014). 

Their  recommendation  is  to  consider  the  “Registry-based  persistence 
mechanisms”  and  consider  only  those  that  one  should  include  versus  exclude.  Some  of 
the  things  to  be  excluded  are  persistent  binaries  signed  by  publishers  and  items  created 
outside  the — if  known — time  frame  examined.  The  Team  should  also  consider  paths  of 
remaining  persistent  binaries  and  critically  look  at  common  directories.  These  are  just 
some  ways  to  focus  the  initial  “triage”  examination  that  is  so  useful  in  further  funneling- 
down  where  additional,  more  in-depth,  incident  research  should  lead  (Luttgens  et  al., 
2014). 
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4. 


Network  Connections 


The  information  in  this  section  is  entirely  based  on  the  work  of  Luttgens  el  al. 

(2014). 

Network  monitoring  is  absolutely  crucial  for  incident  detection.  Because  a 
machine’s  connectedness  to  other  machines  is  via  the  network,  the  network  provides  the 
main  vector  of  attack/exploit  delivery  to  targeted  machines.  There  are  four  network  data 
types  that  can  be  collected  here.  They  are:  alert  data,  session  data,  full  packet  data,  and 
statistical  data. 

Alert  data  tend  to  be  quite  common  for  organizations  to  utilize.  Essentially  an 
alert  is  generated  when  the  alert  sensor  (e.g.,  IDS  or  IPS)  detects  an  event  (or  several) 
that  has  been  deemed  to  be  suspicious,  if  not  explicitly  malicious.  Both  network-based 
and  host-based  intrusion  detection  systems  can  generate  these  alerts. 

Packet  header  data  monitoring  is  useful  but  only  provides  a  portion  of  packet 
capturing  whereas  full  packet  logging  is  just  how  it  sounds  in  that  it  provides  a  more 
thorough  picture  of  what  is  happening.  The  main  purpose  of  full  packet  logging  is  to 
gather  information  that  has  been  exchanged  between  systems  so  that  a  transactional 
“story”  can  be  stitched  together,  and  so  that  signatures  of  interest  can  be  identified.  It  is 
important  to  note  that  at  the  beginning  of  an  incident  investigation,  it  may  be  preferable 
to  initially  cast  a  “wider  net”  and  capture  and  treat  all  data  as  potentially  important,  then 
become  more  narrowly  selective  as  the  course  of  the  investigation  continues. 

High-level  network  statistics  offer  a  “view  of  what  connections,  or  flows,  traverse 
the  network”  (Luttgens  et  al.,  2014,  p.  188).  This  data  can  be  most  helpful  when 
endpoints  involved  in  an  incident  are  not  yet  known.  It  is  also  useful  because  it  aids  in  the 
identification  of  patterns  that  may  otherwise  be  missed  when  looking  at  individual  packet 
or  session  data  that  has  not  been  aggregated  into  the  statistical  big  picture  view. 
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5. 


Tasks 


The  information  discussed  in  this  section  draws  heavily  from  the  work  ofLuttgens 
el  al.  (2014).  All  quoted  material  in  this  section  is  taken  from  this  work,  unless  a  separate 
source  is  explicitly  indicated. 

Scheduled  tasks  provide  another  avenue  by  which  to  research  and  verify  if 
malicious  activity  has  occurred.  “The  Windows  Task  Scheduler  provides  the  ability  to 
automatically  execute  programs  at  a  specific  date  and  time  or  on  a  recurring  basis” 
(Luttgens  et  al.,  2014,  p.  305).  There  are  two  ways  to  create  scheduled  tasks:  the  “at” 
command  and  the  “schtasks”  command. 

There  is  also  a  Management  Console  snap-in  for  manipulating  tasks  in  the  Vista 
and  later  version  of  Windows.  However,  for  the  purposes  of  this  project,  only  at  and 
schtasks  commands  will  be  discussed. 

Creating  a  scheduled  task  can  most  easily  be  done  by  using  the  at  command.  This 
command  requires — at  the  least — local  administrator  privileges.  In  general,  there  are  two 
types  of  tasks  created:  those  for  the  local  host  and  those  for  the  target  host  (remotely 
created  tasks).  Tasks  created  using  the  at  command  have  a  relatively  simple  output. 
However,  there  is  a  fair  number  of  indicators  included,  such  as  the  dates  and  times  for 
when  certain  programs  or  applications  are  to  run.  In  addition,  tasks  can  be  run  in  very 
specified  terms.  For  example,  a  task  can  be  set  to  run  at  03:00  every  Monday, 
Wednesday,  and  Saturday. 

One  important  note  about  creating  tasks  remotely  that  needs  to  be  taken  into 
consideration  is  what  time  zone  the  target  host  is  in.  “Attackers  often  run  the  command 
net  time  WtargetHost  prior  to  scheduling  a  remote  task,  to  check  the  system’s  local  time” 
(Luttgens  et  al.,  2014,  p.  890). 

Whereas  the  at  command  is  a  relatively  simple  one,  the  schtasks  command  is 
more  “full  bodied.”  It  supports  descriptive  names,  even  more  complex  schedules,  and 
many  other  features.  However,  because  schtasks  is  a  more  complicated  command,  it  is 
used  less  frequently  than  the  at  command  by  attackers.  It  is  important  to  note  that  running 
the  at  command  without  parameters  will  only  return  scheduled  tasks  already  created  by 
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the  same  command.  Running  the  schtasks  command  in  the  same  fashion  will,  in  contrast, 
return  scheduled  tasks  created  by  both  the  at  and  schtasks  commands. 


Configuration  information  for  scheduled  tasks  is  stored  in  .job  files  within  the 
%SYSTEMROOTT%\Tasks  directory.  Using  a  hex  editor  one  can  view  the  data 
contained  within  .job  files.  Important  information  can  be  gleaned  by  using  this  method 
that  is  human  readable.  However,  a  tool  that  more  thoroughly  parses  the  .job  files  is 
preferable. 


6.  Accounts 

All  computer  user  accounts  come  with  privileges.  These  privileges  can  increase  or 
decrease  on  two  different  planes. 

When  we  are  attempting  to  gain  access  to  accounts  that  have  a  higher  level 
of  privilege  than  those  that  we  presently  have,  this  is  known  as  vertical 
privilege  escalation.  When  we  are  attempting  to  gain  access  to  different 
accounts  that  what  we  have  access  to,  but  are  at  the  same  level  as  the 
account  that  we  already  have  access  to,  this  is  known  as  horizontal 
privilege  escalation  (Andress  &  Winterfeld,  2014,  p.  4341). 

Once  an  attacker  gains  access  to  the  system  as  a  user,  there  are  a  number  of  ways 
in  which  the  vulnerabilities  of  a  system  may  be  exploited.  In  addition,  what  may  be 
considered  as  a  standard  account  on  a  system  may  already  come  equipped  with  the  ability 
to  act  as  an  administrator,  thereby  immediately  providing  a  hacker  with  greater  access 
and  “mobility”  within  a  system. 

According  to  Luttgens  et  al.  (2014),  privilege  escalation  can  be  attained  through 
password  hash  or  token  dumping  followed  by  password  cracking  or  a  variety  of  other 
methods.  It  is  relevant  to  note  that  a  hacker’s  priority  may  be  to  obtain  access  to  user 
accounts  that  may  not  have  administrative  authority,  but  do  have  access  rights  to  files  or 
resources  that  will  suit  the  hacker’s  needs  nonetheless. 

Regalado  et  al.  (2015)  reference  “power  permissions”  as  they  pertain  to  the  ability 
to  grant  write  access,  read  disposition,  and  execute  disposition.  Permissions  that  allow 
write  access  cause  “rewriting  the  service  configuration  and  granting  immediate  and  direct 
elevation  of  privilege.”  The  “read”  disposition  permissions  also  have  many  potential 
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impacts  when  being  granted  to  untrusted  or  semi-trusted  users.  These  include  revealing 
the  binary  being  run,  what  account  is  being  used  to  run  a  service,  current  state  of  a 
service,  which  services  are  required,  as  well  as  several  others.  The  execute  disposition 
permission  has  to  do  with  the  ability  to  start,  stop,  or  pause  a  given  service.  Suffice  it  to 
say,  that  escalation  of  privileges  is  a  serious  threat  to  systems  (Regalado  et  al.,  (2015). 

7.  Logs 

Event  logs  provide  a  wealth  of  information  for  data  mining.  By  reviewing  event 
logs,  one  can  view  such  system  events  as:  failed  and  successful  logon  attempts,  the  start 
and  stop  of  services,  alterations  to  the  audit  policy,  track  changes  to  permissions,  and 
plenty  of  additional  information  (Luttgens  et  al.,  2014). 

There  are  three  main  event  logs  maintained  by  Windows:  Security,  System,  and 
Application.  Each  of  these  can  be  found  in  a  separate  file  path  stored  in 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog  (Luttgens 
et  al.,  2014).  In  later  versions  of  Windows,  the  default  paths  are: 

•  Security:  %SYSTEMROOT%\System32\Winevt\Logs\Security.evtx 

•  System:  %SYSYTEMROOT%\System32\Winevt\Logs\System.evtx 

•  Application:  SYSTEMROOT%\System32\Winevt\Logs\Application.evtx. 

According  to  Luttgens  et  al.  (2014)  two  essential  items  required  to  fully 

understand  event  logs  are  event  IDs  (EIDs)  and  tracking  and  analyzing  the  events 
themselves.  Every  event  tracked  in  Windows  has  an  affiliated  ID  value.  These  IDs  are 
useful  when  trying  to  research  log  events.  Unfortunately  there  are  hundreds  of  EIDs  that 
may  require  additional  exploration.  However,  to  compensate  for  this,  Microsoft  provides 
the  Events  and  Errors  Message  Center,  which  is  a  search  engine  for  EID  queries.  This 
search  engine  also  provides  the  ability  to  search  for  events  containing  particular  text  or 
which  come  from  specific  sources. 

Understanding  how  to  read  and  interpret  logon  events  is  also  necessary.  There  are 
many  different  things  a  member  of  an  incident  response  team  may  be  searching  for,  like 
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how  a  legitimate  user  accesses  his/her  system,  or  how  a  hacker  gained  remote  access  to  it. 
The  security  event  log  can  provide  answers  to  questions  such  as  these. 

Equally  important  as  the  Security  event  log  is  the  System  event  log.  Any  time  a 
service  is  started  or  stopped,  the  Service  Control  Manager  (SCM)  creates  an  entry  to 
document  the  change.  Unfortunately,  starting,  stopping,  and  changing  services  occurs 
frequently  throughout  the  normal  cycle  of  legitimate  computer  operation,  and  thus  it  is 
difficult  to  distinguish  and  weed-out  those  that  are  malicious  in  intent  from  the  many 
others  that  otherwise  look  so  similar.  When  examining  a  System  event  log,  it  is  preferable 
to  begin  with  a  “known  period  of  attacker  activity”  so  there  will  be  far  fewer  log  entries 
to  parse  and  wade  through.  Another  useful  tool  is  to  search  for  “known-bad”  service 
names  within  the  System  event  log. 

The  Application  event  log  is  the  third  “OS-native”  event  log  from  Windows.  This 
log  is  especially  helpful  when  logged  events  in  either  of  the  other  two  logs  cannot  be 
easily  categorized.  Antivirus  alerts  (in  the  application  log)  that  are  flagged  during  the 
time  in  question  can  help  direct  the  investigation  toward  something  fruitful,  perhaps 
cueing  the  investigator  where  or  what  specifically  to  look  at  in  the  other  two  (security, 
system)  logs  (Luttgens  et  al.,  2014). 

8.  Advanced  Memory  and  Disk  Forensics 

Luttgens  et  al.  (2014)  suggest  that  the  contents  of  memory  (RAM)  is  a  proven 
gold  mine  of  digital  evidence.  While  memory  and  disk  forensics  falls  outside  the  scope  of 
this  project,  it  is  instructive  to  address,  even  if  very  briefly,  this  owing  to  the  tremendous 
amount  of  information  it  is  likely  to  contain  regarding  relevant  incident  artifacts. 

“Memory,”  in  the  case  of  Windows,  entails  both  Random  Access  Memory  (RAM) 
as  well  as  hard  disk  (storage)  to  run  processes.  The  reason  that  the  hard  disk  may  be 
involved  is  in  the  cases  wherein  the  executable  file  may  be  larger  than  the  amount  of 
RAM  used  to  manage  its  execution.  In  such  cases,  most  modern  OSs  (Windows  included) 
maintain  swapped-out  portions  of  the  executable  on  the  hard  drive,  swapping  these 
portions  (pages)  into  and  out  of  RAM  as  calls  are  made  to  functions  that  are  needed.  In 
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the  Windows  OS,  the  pagefile  is  the  main  data  structure  used  to  maintain  this 
coordinating  information. 

“The  term  ‘physical  memory’  simply  refers  to  the  contents  of  RAM”  (Luttgens  et 
al.,  2014,  p.  1027).  In  order  to  explore  its  contents  for  forensic  purposes,  one  must  get  an 
image  of  it.  The  size  of  the  image  will  directly  mirror  the  size  of  RAM.  If  there  are  five 
gigabytes  (GB)  of  RAM,  then  the  image  taken  of  the  physical  memory  will  also  be  five 
GB.  Most  often,  software -based  tools  are  required  to  retrieve  memory  from  a  Windows 
system.  Fortunately,  most  of  these  tools  are  portable  and  can  run  on  a  USB  drive.  In  some 
instances,  the  Firewire  (IEEE13994)  port  can  be  used  to  access  the  physical  memory  of  a 
target  system,  depending  on  the  toolkit  used  (Luttgens  et  al.,  2014). 

Once  an  image  of  the  physical  memory  has  been  attained,  it  has  to  be  translated 
into  a  more  simplistic  format. 

Tools  such  as  the  Volatility  Framework  and  Redline  can  analyze  an 
acquired  memory  image,  recognize  the  intrinsic  structures  associated  with 
user-land  processes  and  the  kernel,  and  parse  them  into  human-readable 
format  (Luttgens  et  al.,  2014,  p.  1029). 

This  parsing  of  information  offers  the  ability  to  view  detailed  process  listings  and 
all  that  is  associated  with  these  processes  (Luttgens  et  al.,  2014). 

The  pagefile  is  a  secondary  storage  space  that  stores  memory  for  processes  that 
cannot  fit  on  the  physical  memory.  It  is  also  connected  with  RAM  in  that,  as  available 
RAM  decreases,  the  pagefile  is  more  active  in  moving  data  back  and  forth.  The  default 
location  for  the  pagefile  is  %SYSTEMDRIVE%pagefile.sys.  However,  its  location  can 
be  moved  or  even  split  over  various  files.  If  it  appears  to  be  missing,  the  Registry  can 
help.  Using  the  key  and  value  HKLM\SYSTEM\CurrentControlSet\Control\Session 
Manager\Memory  M  a n a gc m c n t \P a g  i  n g F i  1  e s  can  help  determine  if  another  path  has  been 
used.  Once  it  has  been  located,  it  cannot  simply  be  copied  using  Windows  Explorer  or  the 
command  shell.  A  specific  forensic  utility  is  needed  to  get  a  copy  of  the  pagefile  from  a 
running  system. 

Crash  dumps  can  be  an  effective  way  to  analyze  what  went  wrong  that  caused  a 
system  crash.  There  are  three  levels  of  crash  dumps:  Kernel  Memory  Dump,  Small 
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Memory  Dump,  and  Complete  Memory  Dump.  The  information  that  can  come  from 
these  “dumps”  can  be  pivotal  during  an  investigation  because  it  can  provide  data  about 
the  running  processes,  kernel  data  as  well  as  other  activities  that  were  occurring  at  the 
time  of  the  crash. 

Reviewing  the  process  listing  can  also  be  beneficial  to  an  investigation. 
Essentially,  the  process  listing  provides  information  as  to  what  is  running  on  a  system. 
Executive  Process  (EPROCESS)  blocks  provide  kernel  data  about  these  mnning 
processes.  Performing  memory  forensics  can  extract  things  like  process  ID,  process 
name,  process  command  line,  etc.,  from  the  list  of  EPROCESS  blocks  in  kernel  memory. 
It  is  relevant  to  note  that  the  tool  used  will  have  to  map  out  the  parent-child  relationships 
among  the  data  extracted  into  a  hierarchy  tree.  This  is  because  “processes  only  track  their 
parent  process  ID  (PID)  and  not  the  parent  process  name  or  path”  (Luttgens  et  al.,  2014, 
p.  361). 

Because  deep  memory  forensics  falls  outside  the  scope  of  this  project,  further 
detail  is  not  necessary.  However,  other  memory  artifacts  that  can  provide  additional 
evidence  are  those  of  network  connections,  loaded  drivers,  console  command  history, 
strings  in  memory,  and  credentials  (Luttgens  et  al.,  2014). 

B.  NETWORK  SERVICES  AND  APPLICATIONS 

Though  there  are  many  areas  within  the  WOC  that  may  be  attacked,  there  are 
others  that  exist  outside  of  this  domain.  These  can  be  found  in  network  services  and 
applications.  Things  like  the  DHCP,  DNS,  web  applications,  and  Email  are  all  additional 
surface  areas  outside  of  the  end  device’s  OS  that  present  potential  for  attack. 

1.  Dynamic  Host  Configuration  Protocol 

Dynamic  Host  Configuration  Protocol  (DHCP)  is  a  framework  which  hackers  are 
able  to  subvert.  Essentially,  the  main  purpose  of  DHCP  is  to  assign  Internet  Protocol  (IP) 
addresses  to  devices  connected  to  the  network  (Luttgens  et  al.,  2014).  Therefore,  it  is  no 
surprise  that  this  mechanism  provides  an  opportunity  for  malicious  activity. 
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An  example  of  this  is  DHCP  spoofing.  It  begins  with  a  DHCP  client  broadcasting 
a  DHCPDISCOVER  packet  over  the  network. 

All  listening  and  active  DHCP  servers  would  respond  with  DHCPOFFER 
packets  offering  a  list  of  configuration  parameters.  The  client  then 
responds  to  one  of  the  DHCPOFFERs  with  a  DHCPREQUEST  packet. 

The  server  completes  the  initialization  process  by  transmitting  a 
DHCPACK  packet  (Schiffman,  O’Donnell,  Pennington,  &  Pollino,  2003, 
p.  2903). 

During  the  DHCP  packet  exchange,  an  IP  address,  routing  and  Domain  Name 
System  (DNS)  information  to  the  DHCP  client.  Someone  with  ill  intention  could 
impersonate  the  DHCP  server.  They  would  be  able  to  send  a  valid  IP  with  invalid  routing 
information.  This  would  enable  the  hacker  to  view  any  and  all  traffic  being  transmitted 
over  the  connection  (Schiffman  et  al.,  2003). 

2.  Domain  Name  System 

The  Domain  Name  System  (DNS)  is  the  answer  to  an  ever-broadening  and  vast 
Internet.  DNS  provides  a  mapping  between  alpha-numeric  names  of  Internet  addresses 
that  are  easier  to  use.  This  differs  from  IP  addresses,  which  are  purely  numeric.  An 
example  is  www.metsblog.com.  Its  corresponding  IP  address  is  192.0.79.32.  “It  is 
impossible  to  have  one  single  host  file  to  relate  every  address  with  a  name  and  vice 
versa”  (Forouzan,  2010,  p.  12206).  The  resolution  to  the  original  host  file  and  its 
limitations  for  maintaining  such  a  massive  amount  of  information  is  the  distributed  and 
interactive  functionality  provided  by  the  DNS.  Name-to-IP  mapping  information  is 
divided  into  smaller  parts  and  spread  across  numerous  DNS  servers  located  throughout 
the  Internet  (Schiffman  et  al.,  2003). 

At  its  very  base,  the  use  of  the  DNS  involves  query-reply-based  communication 
between  name  clients  and  name  servers  for  the  purpose  of  the  clients  obtaining  IP 
addresses  of  servers  known  only  by  name  (Forouzan,  2010).  As  with  any  external 
transmission  of  data,  there  is  risk  of  interception  and/or  alteration  of  access  points.  DNS 
spoofing  involves  a  malicious  user  “listening”  for  DNS  requests  and  responding  with  an 
IP  address  of  their  own  choosing  (with  such  choice  NOT  being  a  legitimate  DNS  server). 
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This  would  allow  the  malicious  spoofer  to  “redirect  all  outgoing  traffic  through  itself 
before  forwarding  the  traffic  along  on  its  correct  path;  thus  creating  a  “man  in  the 
middle”  situation.  A  fully  switched  network  would  appear  to  get  in  the  way  of  attackers 
sniffing  data  not  directed  to  them.  However,  there  are  various  ways  in  which  a  switch  can 
be  compromised,  resulting  in  the  device  being  forced  to  forward  or  flood  packets  that 
would  not  have  otherwise  gone  to  the  attacker  (Schiffman  et  al.,  2003). 

3.  Web 

Liston  and  Skoudis  (2006)  argue  that  web  application  attacks  have  emerged  as  an 
ever  more  popular  method  of  exploiting  hosts.  Because  the  Internet  is  used  for  things  like 
ecommerce,  trading,  voting,  government,  services,  etc.,  it  provides  a  large  target  of 
opportunity  for  nefarious  actors.  A  common  misconception  is  that,  if  a  Secure  Sockets 
Layer  (SSL)  is  being  implemented,  the  connection  between  the  user  and  a  site  is 
impenetrable.  While  SSL  does  reinforce  authentication  and  help  protect  data  in  transit,  it 
does  not  mean  that  there  is  not  any  adversarial  “work  arounds”  to  get  past  this  security 
protocol.  Account  harvesting  and  the  undermining  of  Web  application  session  tracking 
can  both  be  done,  even  with  SSL  in  place. 

Account  harvesting  can  be  accomplished  when  a  user  attempts  to  log  in  to  a  site 
with  the  incorrect  user  identification.  It  can  also  occur  when  a  user  has  the  correct  user 
identification  but  the  incorrect  password.  These  are  two  separate  attempt  types  and  may 
not  have  been  tried  by  the  same  perpetrator.  This  happens  because  even  though  both 
attempts  would  be  denied,  the  browser  header  response  is  different  for  each.  They  would 
look  exactly  the  same  with  the  exception  of  the  end  note.  The  first  may  return  an  error  1 
notice  whereas  the  latter  would  return  an  error  2  notice.  It  is  exactly  this  variance  that  an 
attacker  would  look  for. 

Another  way  in  which  Web  applications  can  be  exploited  is  via  a  browser’s 
cookies.  “A  cookie  is  simply  an  HTTP  field  that  the  browser  stores  on  behalf  of  a  Web 
server”  (Liston  &  Skoudis,  2006,  p.  412).  There  are  two  types  of  cookies:  persistent  and 
non-persistent.  A  persistent  cookie  is  one  that  is  written  to  a  local  file  on  the  client 
machine  upon  the  closing  of  a  browser.  It  will  be  read  by  the  Web  server  that  created  it 
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when  the  client  returns  to  that  Web  server.  A  non-persistent  cookie,  on  the  other  hand,  is 
simply  “forgotten”  (not  saved  to  memory)  when  the  browser  is  closed. 

If  a  session  is  tracked  via  persistent  cookies,  a  nefarious  user  could  edit  the  local 
cookie  file.  According  to  Skoudis  &  Liston  (2006): 

For  Internet  Explorer,  cookies  from  different  servers  are  stored  in  their 
own  individual  files  in  the  Temporary  Internet  Files  directory  for  each 
user... To  exploit  a  session  ID  based  on  a  persistent  cookie,  the  attacker 
can  log  in  to  the  application  to  get  a  session  ID,  close  the  browser  to  write 
the  cookie  file,  edit  the  cookies  using  his  or  her  favorite  text  editor  and 
relaunch  the  browser,  now  using  the  new  session  ID  (Skoudis  &  Liston, 

2006,  p.  414) 

This  can  be  relatively  easily  accomplished  without  the  user  ever  realizing  what  has 
occurred. 

4.  Email 

Email  is  arguably  the  most  utilized  source  of  commercial  communication,  and  its 
worldwide  usage  continues  to  advance  at  a  rapid  pace.  It  is  precisely  because  of  this  that 
it  can  be  used  as  a  prime  target  for  malicious  purposes.  Email  content  can  be  broken 
down  into  two  sections:  body  and  header.  The  body  consists  of  content — including 
attachments — whereas  the  header  is  a  compilation  of  sender  and  recipient  email 
addresses,  timestamps,  server  information  and  more. 

Luttgens,  Mandia,  and  Pepe  (2014)  reference  the  four  most  common  types  of 
email  they  have  encountered  as  Microsoft  Outlook  for  Windows,  Microsoft  Outlook  for 
OS  X,  Apple  Mail,  and  Web  mail.  For  the  purposes  of  this  project,  we  will  concentrate  on 
Web  mail  and  Microsoft  Outlook. 

Web  mail  pertains  to  services  like  Gmail,  Yahoo!,  and  AOL.  It  is  not  typical  for 
these  types  of  services  to  store  content  on  a  local  system.  In  the  case  of  web  mail,  most 
information  attained  will  likely  come  in  the  form  of  browser  artifacts.  In  addition, 
because  Web-based  email  services  are  continuously  changing,  “traditional”  tools  are  less 
likely  to  provide  a  thorough  analysis  of  what  may  have  transpired  within  an  individual 
account.  However,  a  “well-maintained  specialized  tool”  may  offer  more  of  an  advantage 
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when  attempting  to  discover  artifacts.  Perhaps  the  most  effective  method  for  examining 
Web  mail  information  is  to  narrow  the  time  frame  of  suspected  malicious  behavior  first, 
and  then  investigate  all  aspects  of  the  system  that  could  potentially  be  impacted.  These 
include  browser  history,  Registry  logs,  file  system,  etc.  This  may  provide  the  best  way  to 
get  an  all-inclusive  picture  as  to  what  happened. 

Microsoft  Outlook  is  a  major  email  client  that  is  utilized  by  a  plethora  of  companies 
and  agencies.  One  of  the  reasons  for  this  is  that  it  supports  many  different  protocols.  For 
example,  Outlook  can  operate  with  Post  Office  Protocol  (POP),  Internet  Message  Access 
Protocol  (IMAP),  Microsoft  Exchange,  and  a  number  of  Web  (or  HTTP)  based  services. 
These  are  independent  of  the  third  party  add-ins  that  provide  even  more  capabilities  to 
Outlook.  It  is  important  to  note  that  the  directories  where  Outlook  files  are  located  by 
default  can  be  modified  by  the  user.  A  good  place  to  begin  looking  is 
HKEY_CURRENT_USER\Software\Microsoft\Office\[version]\Outlook\Search\Catalog. 
“Version”  here  refers  to  the  Office  version  number. 

In  addition,  Outlook  has  the  capacity  for  configuring  multiple  “profiles.”  These 
profiles  are  stored  under  a  different  location  than  the  one  aforementioned.  A  default 
profile  is  useful  so  that  it  can  be  eliminated  from  any  additional  profiles  subsequently 
created. 

The  data  format  that  is  used  by  Outlook  is  the  Personal  Folder  File  (PFF). 
Outlook  will  also  store  an  email  copy  offline  in  the  Offline  Storage  Table  (OST).  These 
files  can  be  analyzed  by  two  different  types  of  tools:  commercial  forensics  tools  and  open 
source  tools.  These  types  of  tools  have  the  capability  to  view  the  file  structure  and  display 
the  file  contents  as  a  tree,  as  well  as  compile  an  executable  using  “libpff  ’  that  can  export 
files  (Luttgens  et  al.,  2014). 

Just  as  important  as  recognizing  and  making  proper  use  of  IOCs  is  the  ability  to 
have  a  firm  grasp  of  the  prominent  incident  investigative  tools  used  in  the  field. 
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IV.  PROMINENT  INCIDENT  INVESTIGATIVE  TOOLS 


One  of  the  most  essential  keys  to  effective  incident  response  is  to  be  both 
knowledgeable  about,  and  able  to  “cultivate”  (i.e.,  modify,  improve,  extend)  the  tools 
involved.  For  situations  where  any  number  of  tools  can  be  utilized,  the  best  place  to  start 
is  by  investigating  the  most  prominent  tools  available.  Some  items  include  use  of  the 
command  line,  TCPview,  and  Regshot,  but  the  list  is  not  necessarily  limited  to  these 
items.  However,  as  these  specific  tools  pertain  to  the  scenarios  described  later,  these  are 
the  tools  highlighted  and  addressed  here. 

A.  ABSENCE  OF  DEEP  FORENSICS 

The  term  digital  forensics  is  an  exceptionally  broad  term  and  can  be  used  when 
referring  to  numerous  aspects  of  the  process  of  incident  response.  Dezfoli  et  al.  (2013) 
define  digital  forensics  as  the  process  that  “involves  collection,  preservation,  analysis  and 
presentation  of  evidence  from  digital  sources”  (p.  48).  Because  there  are  many  digital 
sources,  this  definition  encompasses  a  wide  variety  of  potential  evidence,  it  is  difficult  to 
narrow  down  all  that  it  entails.  It  is  precisely  for  this  reason  that  the  tools  and  methods 
presented  here  are  intended  to  illustrate  a  “broad  stroke”  of  all  that  is  available.  It  is 
necessary  to  differentiate  between  what  is  to  be  considered  an  incident  responder  versus  a 
digital  forensics  expert.  Essentially,  an  incident  responder  is  similar  to  an  emergency  first 
responder  (medical,  rescue,  or  law  enforcement).  These  are  the  individuals  who  know  the 
essentials  and  can  get  a  person  (or  organization)  back  to  a  stabilized  functioning  state. 
Pursuing  the  medical  first  responder  analogy  further,  the  digital  forensics  expert  is  more 
akin  to  a  surgeon;  someone  with  deeper  technical  understanding  who  is  able  to  discern 
the  “root  cause”  of  an  ailment  and  render  sophisticated  remedies.  Incident  responders 
have  a  certain  set  of  “quick  react”  skills  and  tools,  whereas  a  digital  forensics  expert  will 
rely  on  more  specialized  knowledge  and  tools.  Forensic  Toolkit  (FTK),  EnCase,  and 
IDAPro  are  all  examples  of  more  “industrial-strength”  malware  analysis  tools  that  are 
often  utilized  by  digital  forensic  experts.  While  these  tools  are  slightly  beyond  the  scope 
of  this  research,  they  do  require  discussion. 
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FTK  is  a  major  digital  forensics  software  tool  created  by  AccessData.  It  has 
capabilities  that  include  broad  encryption  support,  comprehensive  index  and  binary 
search,  Internet  and  chat  analysis,  and  single-node  remote  investigations.  In  addition,  it 
also  incorporates  a  standalone  disk  imager  that  calculates  hash  values  and  can  be  saved  in 
several  format  types.  This  is  more  of  an  all-inclusive  tool  and  something  that  would  more 
likely  be  used  by  a  digital  forensics  expert  as  opposed  to  an  incident  responder. 

EnCase  is  another  example  of  a  major  contender  in  the  market  for  digital 
forensics  software.  It  is  developed  by  Guidance  Software  and  offers  a  great  deal  in  terms 
of  not  only  thorough  investigation  but  specialized  investigation  by  issue  and/or  industry. 
Fields  like  financial  services,  healthcare,  government  and  law  enforcement  can  all  benefit 
from  this  software.  In  addition,  the  output  of  this  software  can  be  accepted  as  evidence  in 
court.  Again,  this  is  outside  of  the  focus  of  this  work,  but  it  is  worth  knowing  that  this 
type  of  product  is  available. 

IDAPro  differs  from  the  aforementioned  software  in  that  it  is  more  narrowly 
focused  as  a  multi-processor  disassembler  and  debugger  intended  to  map  the  execution 
space  of  executable  code.  Per  Sikorski  and  Honig  (2012),  there  are  levels  of  languages 
used  when  discussing  the  operation  of  malware.  These  include  high-level  language, 
machine  code,  and  low  level  language  (typically  assembly).  Malware  creators  typically 
create  their  code  using  a  high-level  language  that  is  subsequently  compiled  into  machine 
code  in  order  to  be  in  executable  form.  This  differs  from  the  situation  where  analysts 
operate,  which  usually  entails  starting  at  the  machine  code  level,  then  possibly 
disassembling  it  into  more  human-readable  assembly  code.  Analysts  reverse  engineer  this 
assembly  code  to  determine  how  it  works  as  well  as  its  purpose.  Reverse  engineering 
refers  to  breaking  down  the  whole  to  view  and  understand  its  working  parts.  It  is  an 
invaluable  tool  for  an  incident  response  team  to  utilize. 

All  of  these  programs  can  provide  intense  and  thorough  evaluations  of  a  given 

system  or  systems.  However,  the  focus  of  this  research  has  been  to  demonstrate  a  bigger 

picture  of  the  techniques,  methodologies,  and  tools  utilized  in  incident  response.  The 

reliance  here  is  on  the  things  that  can  be  learned  and  understood  by  the  incident 

responder  quickly.  It  also  is  to  provide  a  foundation  for  the  argument  that  the  rudimentary 
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skills  of  incident  response  can  be  learned  via  interaction  with  incidents  that  have  been 
conveniently  captured  in  highly  portable  VMs. 

B.  DEDICATED  UTILITIES 

1.  Quick  Checksum  Verifier 

Quick  Checksum  Verifier  (QVC)  is  a  tool  that  is  used  to  determine  if  there  has 
been  a  change  in  a  document  or  file  by  using  MD-5  or  SHA-1  hash  functions.  A  file  is 
loaded  into  the  QVC  and  a  hash  value  is  created.  It  is  important  to  note  that  a  hash  is  a 
numerical  value  obtained  from  text  and  a  one-way  function/algorithm.  The  created  hash 
value  is  saved  and  compared  to  future  hash  values  of  the  file.  At  any  future  time  one  may 
verify  the  integrity  of  the  file  by  re-hashing  it  and  comparing  the  newly  generated  hash 
value  to  the  original  for  that  file.  If  the  values  differ,  something  in  the  file  has  changed 
(lost  integrity). 

2.  PEView 

Sikorski  and  Honig  (2012)  reference  the  Portable  Executable  (PE)  view  as  an 
excellent  tool  for  viewing  the  PE  file  structure.  It  allows  the  user  to  view  valuable  header 
information,  individual  sections,  as  well  as  import  and  export  tables.  It  is  through  the  use 
of  PEView  that  thread  local  storage  (TLS)  callbacks  can  be  effectively  utilized. 

Many  people  assume  that  when  they  load  a  program  into  a  debugger,  the  process 
will  pause  as  soon  as  the  program  executes  an  instruction.  However,  this  does  not  always 
happen.  The  majority  of  debuggers  actually  begin  where  the  PE  header  defines  the 
program’s  entry  point  to  be.  The  benefit  of  a  TLS  callback  is  that  it  can  execute  before 
the  designated  entry  point,  and  thereby  execute  secretly. 

Basically,  TLS  allows  each  thread  to  maintain  a  different  value  for  a 
variable  declared  using  TLS.  When  TLS  is  implemented  by  an  executable, 
the  code  will  typically  contain  a  .tls  section  in  the  PE  header...  TLS 
supports  callback  functions  for  initialization  and  termination  of  TLS  data 
objects  (Sikorski  &  Honig,  2012,  p.  9310). 
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A  way  to  discover  TLS  callbacks  is  to  review  the  .tls  section  through  PEview. 
“Normally  functioning”  programs  do  not  usually  use  the  .tls  section,  so  if  it  is  there  it 
should  be  considered  a  red  flag. 

3.  Process  Explorer 

Another  useful  tool  for  researching  whether  malicious  activity  is  happening  is 
through  Process  Explorer.  Essentially,  it  is  an  extremely  powerful  task  manager.  Process 
Explorer  monitors  and  displays  processes  in  a  tree  format  that  clearly  shows  the  parent 
and  child  relationships  among  the  processes.  In  addition  to  the  formatting,  further 
organization  and  clarity  of  function  is  displayed  with  color-coding.  New  processes — 
coded  in  green — tend  to  be  the  primary  source  for  initial  investigation. 

4.  TCPView 

TCPview  is  used  to  detect  potential  malicious  attacks  to  the  network.  It  has  the 
capability  of  graphically  displaying  detailed  listings  of  all  endpoints  (TCP  and  UDP)  on 
the  system.  It  can  be  helpful  in  the  event  a  process  is  connecting  over  a  port  but  what 
process  is  making  the  connection  is  unknown  (Sikorski  &  Honig,  2012). 

5.  Regshot 

Regshot  allows  for  Registry  comparison  by  taking  snapshots  of  a  pre-infected  and 
post-infected  system.  This  allows  the  incident  response  team  to  evaluate  what  changes 
are  made  to  the  system  by  the  particular  malware  that  was  used.  Unfortunately,  the  results 
will  often  require  plenty  of  patient  scanning  and  comparison  to  decipher  where  the 
pertinent  information  is. 

C.  COMMAND  LINE 

The  command  line  is  a  great  tool  for  cyber  defenders.  This  tool  is  built  into  every 
Windows  operating  system.  Many  prefer  the  graphical  tools  because  it  is  easier  to  look  at 
and  decipher  information.  The  fact  of  the  matter  is  the  graphical  tools  could  be 
compromised  or  may  not  be  available  all  together  during  a  cyber  emergency.  In  addition, 
execution  of  graphical  tools  on  a  potentially  infected  system  may  cause  new  processes 
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and  files  to  be  generated  or  opened,  thereby  modifying  the  operational  state  of  the 
system.  This  could  actually  corrupt  forensic  data.  However,  if  graphical  tools  are  still 
preferred,  having  a  knowledge  of  certain  basic  commands  should  be  acquired. 

1.  Netstat 

Just  like  the  graphical  tool  TCPview,  utilizing  this  command  with  its  parameters 
allows  an  IT  professional  to  monitor  network  connections.  By  inputting  the  command 
netstat  ?  a  person  can  see  all  the  parameters  that  netstat  provides.  This  is  illustrated  in 
Figures  1,  2  and  3. 


Figure  1.  Netstat  Parameters  View 


Netstat?  shows  parameters  used  with  netstat. 
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Figure  2.  Netstat  View  2 
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Netstat  -a  displays  all  active  connections. 
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Figure  3.  Continuation  of  Netstat  -a 


2.  Viewing  Events 

Windows  has  what  is  known  as  the  Event  Viewer,  which  logs  many  events  that 
are  deemed  most  useful  for  system  monitoring  and  troubleshooting.  It  also  has  an  audit 
setting  that  allows  the  operator  to  tailor  what  they  wish  to  view.  For  example:  the  user 
may  indicate  there  are  specific  kinds  events  they  want  logged  or  they  may  adjust  for  the 
degree  of  detail  provided  for  the  events  that  are  logged.  The  events  that  are  logged  can  be 
viewed  through  the  command  line  without  accessing  the  tool  using  powershell.  Figure  4 
shows  one  (security)  of  the  three  principal  logs  accessible  by  Event  Viewer.  This  output 
is  obtainable  by  use  of  the  command  get-eventlog  “security.”  The  name  within  the 
quotations  is  the  name  of  the  log  you  want  to  view.  This  command  allows  an 
administrator  to  view  security  log  entries  that  have  not  been  deleted.  The  output  shown 
was  further  narrowed  by  appending  the  command  modifier,  “-newest  20,”  to  the 
command  so  as  to  only  display  the  most  recent  20  log  entries. 
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Figure  4.  Command  Get-eventlog  “Security”-Newest  20 
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PS  c:\Windows\system32> 
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Shows  the  20  newest  entries  in  the  security  log 


3.  Viewing  Processes  and  Services 

Just  like  Process  Explorer,  the  tasklist  command  shows  all  processes  and  services 
running  on  a  machine,  as  displayed  in  Figure  5. 
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Figure  5.  Tasklist  Command 


All  running  processes  and  services 


4.  System  File  Integrity 

It  is  very  common  for  attackers  to  manipulate  or  replace  files  in  order  to  gain 
system  level  access  to  Windows  systems.  For  this  reason,  it  is  a  good  idea  to  verify  the 
hash  signatures  of  suspect  files.  The  Windows  tool  System  File  Checker  verifies  the 
signature  of  files,  and  if  they  are  not  found  or  are  fraudulent,  they  will  be  replaced  by  the 
tool.  The  tool  is  run  with  the  command  sigverif  as  illustrated  in  Figure  6. 


41 


Figure  6.  Command  SIGVERIF 


_  □ 


The  following  files  have  not  been  digitally  signed: 


Name 


ime  In  Folder  Modified  File  Type  Versio 

vimbase.dll  c:\windows\syste...  10/29/2014  Application...  10.1.25.; 


Signature  Verification  Results 


□ 


Close 


Files  found:  409.  Signed  files:  408.  Unsigned  files:  1.  Files  not  scanned:  0. 


Vimbase.dll  has  been  found  to  not  have  a  digital  signature. 


5.  File  or  Document  Integrity 

Whereas  system  files  are  computer  files  that  the  OS  uses  to  function  properly,  a 
“regular”  file  stores  information  created  by  users.  Much  like  the  Quick  Checksum 
Verifier,  the  information  provided  via  the  dir  command  allows  an  administrator  to  tell 
when  files  or  documents  have  been  modified.  If  it  is  known  that  such  files  should  not 
have  been  modified,  it  would  be  a  good  idea  to  investigate  further.  This  is  illustrated  by 
Figures  7  and  8. 
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Figure  7.  View  of  Files 


The  document  G  was  modified  at  1:56  p.m.  on  August  25. 

Figure  8.  Command  Dir  /T:W 


The  date  and  time  the  document  G  was  last  modified. 
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V.  INCIDENT  RESPONSE  LAB  SCENARIOS 


The  scenarios  provided  in  this  chapter  offer  guided  practical  exercises  that 
provide  realistic  experiences  with  compromised  systems  (captured  as  VM).  These 
provide  the  incident  responder  with  the  opportunity  to  make  informed  decisions 
regarding  which  artifacts  should  be  examined  as  well  as  which  tools  are  best  suited  for 
each  situation. 

A.  SCENARIO  1— DOCUMENT  AND  FILE  INTEGRITY 

(1)  Target  Time  to  Complete:  30  minutes 

(2)  Lab  Description:  Use  the  Quick  Checksum  Verifier  (QCV)  to  confirm 
the  integrity  of  documents  and  files. 

(3)  Expected  Knowledge,  Skills  and  Abilities  to  Complete:  The  student  will 
need  to  know  what  hashes  are  and  that  hashes  are  used  by  tools  such  as  the 
QCV  to  confirm  the  integrity  of  files  and  documents. 

(4)  Source  VM  and  System  Requirements  to  Run:  In  order  to  conduct  this 
lab,  VMware  Workstation  must  be  installed.  This  lab  scenario  uses  the 
Windows  8  operating  system. 

(5)  Lab  Setup:  The  instructor  will  add  100  files  and  documents  to  the  desktop 
and  construct  a  Master  Hash  Printout  for  all  files  and  documents.  One 
paragraph  of  the  file  Lab2a  will  be  deleted  by  the  instructor.  The  instructor 
will  then  clone  the  VMware  Workstation  lab  environment  and  name  it  Lab 
1  for  future  student  use. 

(6)  Lab  Write  Up  and  Analysis 

(i)  Title:  File  and  Document  Integrity 

(ii)  Introduction:  The  purpose  of  the  lab  is  to  teach  the  student  how  to 
operate  a  file  integrity  tool  to  determine  if  a  file  has  been  changed. 
The  student  will  need  to  know  how  to  operate  the  QCV  and  how  to 
compare  the  tool’s  output  hash  with  the  hash  on  the  Master  Hash 
Printout.  Also,  this  lab  teaches  the  student  how  painful  it  can  be  to 
check  the  integrity  of  multiple  files  with  a  tool  like  QCV. 

(iii)  Tools:  QCV  is  a  tool  that  is  used  to  determine  if  there  has  been  a 
change  in  a  document  or  file  using  MD-5  or  SHA-1  hash  functions.  A 
file  is  loaded  into  the  QVC  and  a  hash  value  is  created.  The  created 
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hash  value  is  saved  and  compared  to  future  values  of  the  file  to 
determine  if  the  file  has  been  modified. 

(iv)  Results:  Provide  screen  shots  with  a  brief  description  that  convey 
pertinent  indicators  of  compromise.  This  is  depicted  by  Figures  9  and 
10. 


Figure  9.  List  of  Flashes  Taken  on  All  Files  Before  the  Start  of  the  Lab 
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Figure  10.  Hash  Value  for  File  Lab  2a  after  a  One  Paragraph  Deletion 
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To  load  the  file  into  the  tool,  click  the  folder  that  is  to  the  right  of  the  path 
window.  The  student  should  observe  that  the  hash  is  different  than  the  hash  on  the  Master 
Hash  File. 

B.  SCENARIO  2— USE  WINDOWS  EVENT  VIEWER  TO  LOOK  FOR 
SUSPICIOUS  EVENTS 

(1)  Target  Time  to  Complete:  30  minutes 

(2)  Lab  Description:  Utilize  Windows  Event  Viewer  to  look  through  200 
Windows  events.  Use  screen  shot  suspicious  events  for  the  lab  write  up. 

(3)  Expected  Knowledge,  Skills  and  Abilities  to  Complete:  The  student  will 
need  to  know  what  the  application,  security,  and  system  event  logs  are, 
and  that  the  Event  Viewer  is  the  built-in  Windows  utility  used  to 
view/review  them.  The  student  will  inspect  one  or  more  of  Windows’ 
three  native  logs  to  determine  if  an  incident  has  occurred. 

(4)  Source  VM  and  System  Requirements  to  Run:  In  order  to  conduct  this 
lab,  VMware  Horizon  Client  must  be  installed.  This  lab  scenario  uses  a 
Windows  7  operating  system. 

(5)  Lab  Set  Up:  Malware  will  be  executed  in  the  virtual  environment.  This 
malware  should  be  downloaded  from  the  EC-Council  CEHV8  Module  07 
DVD  located  in  the  Viruses  and  Worms  folder.  After  the  instructor 
confirms  that  there  are  200  events  in  the  event  viewer  and  the  malware  is 
executed,  a  clone  of  the  VMware  Workstation  environment  will  be  taken 
by  the  instructor  and  named  Lab2  for  future  student  use.  For  this  scenario 
the  student  will  be  told  there  are  only  four  user  accounts:  Matthew,  Kira, 
George,  and  Ted.  Also,  executables  are  not  allowed  on  this  particular 
machine. 

(6)  Lab  Write  Up  and  Analysis 

(i)  Title:  Using  Event  Viewer 

(ii)  Introduction:  The  purpose  of  the  lab  is  to  teach  the  student  how  to 
operate  and  read  the  Event  Viewer  Utility.  Looking  at  logs  is  a 
painstaking  process  and  can  be  very  difficult  to  spot  suspicious 
behavior  when  you  are  looking  through  thousands  of  line  items.  It 
takes  a  good  deal  of  time  to  go  through  200  events. 

(iii)  Tools:  Event  Viewer  was  utilized  to  discover  suspicious  activity  for 
this  lab.  Event  logs  provide  a  wealth  of  information  for  data  mining. 
By  reviewing  event  logs,  one  can  view  such  system  events  as:  failed 
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and  successful  logon  attempts,  the  start  and  stop  of  services, 
alterations  to  the  audit  policy,  track  changes  to  permissions,  and 
plenty  of  additional  information  (Luttgens  et  al.,  2014). 

There  are  three  main  event  logs  maintained  by  Windows:  Security, 
System,  and  Application.  Each  of  these  can  be  found  in  a  separate  file 
path  stored  in  HKEY_LOCAL_MACHINE\ 
SYSTEM\CurrentControlSet\Services\Eventlog  (Luttgens  et  al., 
2014). 

(iv)  Results:  Provide  screen  shots  with  a  brief  description  that  convey 
pertinent  indicators  of  compromise.  This  can  be  seen  in  Figures  11 
and  12. 


Figure  11.  Security  Log 


This  username  is  not  one  of  the  four  authorized  accounts  for  this  machine. 
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Figure  12.  Application  Log 
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Here  it  shows  the  problem  signature  blem.exe.  Executables  are  unauthorized. 

SCENARIO  3— ANALYSIS  OF  NETWORK  CONNECTIONS 


(1)  Target  Time  to  Complete:  30  minutes 

(2)  Lab  Description:  Use  TCPview  to  look  through  two  weeks  of  saved 
network  connections.  Screen  shot  suspicious  connections  for  the  lab  write 
up. 

(3)  Expected  Knowledge,  Skills  and  Abilities  to  Complete:  The  student 
must  know  what  the  TCPView  utility  is  used  for  monitoring  network 
connections  specifically  TCP  and  UDP  endpoints. 

(4)  Source  YM  and  System  Requirements  to  Run:  In  order  to  conduct  this 
lab  VMware  Workstation  must  be  installed.  This  lab  scenario  uses  the 
Windows  7  operating  system. 

(5)  Lab  Setup:  Malware  will  be  executed  in  the  virtual  environment.  The 
malware  is  downloaded  from  the  EC-Council  CEHV8  Module  07  DVD 
located  in  the  Viruses  and  Worms  folder.  Once  the  instructor  has  sufficient 
saved  network  connections  in  the  TCPview  tool  and  the  malware  has  been 
executed  the  instructor  will  clone  the  VMware  Workstation  lab 
environment  and  name  it  Lab3  for  future  student  use. 
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Lab  Write  Up  and  Analysis: 

(i)  Title:  Analysis  of  Network  Connections  Introduction 

(ii)  Introduction:  The  purpose  of  the  lab  is  to  teach  the  student  how  to 
operate  and  decipher  network  connections  using  TCPView. 
Sometimes  it  can  be  very  difficult  to  determine  if  a  network 
connection  is  malicious  or  not  because  many  attackers  are  good  at 
hiding  malicious  connections  in  plain  sight.  In  order  to  detect 
malicious  network  connections  defenders  must  constantly  monitor 
network  activity  with  tools. 

(iii)  Tools:  TCPview  is  used  to  detect  potential  malicious  attacks  to  the 
network.  It  has  the  capability  of  graphically  displaying  detailed 
listings  of  all  endpoints  (TCP  and  UDP)  on  the  system.  It  can  be 
helpful  in  the  event  that  a  process  connects  over  a  port  but  what 
process  is  making  the  connection  is  unknown  (Sikorski.  &  Honig, 
2012) 

(iv)  Results:  Provide  screen  shots  with  a  brief  description  that  convey 
pertinent  indicators  of  compromise.  These  can  be  viewed  in  Figures 
13  and  14. 


Figure  13.  TCPView 
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Figure  14.  TCPView — Firefox  Connections 
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These  Firefox  connections  are  suspicious.  The  firefox.exe  processes  have  the 
same  process  identifier  and  are  communicating  on  local  ports  49191-4923.  Forty  TCP 
endpoints  is  very  high  for  one  process  identifier.  The  remote  ports  are  http  or  https,  which 
are  very  common  ports  used  by  attackers.  These  remote  ports  are  usually  not  being 
watched  or  blocked  by  defenders  due  to  their  heavy  network  traffic.  In  addition,  these 
ports  are  usually  open  for  authorized  use. 

D.  SCENARIO  4— PROCESS  OR  SERVICE  ANALYSIS 

(1)  Target  Time  to  Complete:  30  minutes 

(2)  Lab  Description:  Monitor  processes  and  services  with  Process  Explorer. 
Suspicious  events  are  captured  using  screen  shots  for  the  lab  write  up. 

(3)  Expected  Knowledge,  Skills  and  Abilities  to  Complete:  The  student  will 
need  to  know  how  to  properly  read  the  process  explorer  output  and  also 
how  to  spot  service  or  processes  that  may  be  malicious.  The  student  will 
need  to  know  what  the  colors  pink,  blue,  green,  and  red  mean  when  the 
process  viewer  highlights  the  various  services  and  processes.  Also,  the 
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student  will  need  to  know  what  a  malicious  service  or  process  looks  like 
within  the  process  viewer. 

(4)  Source  VM  and  System  Requirements  to  Run:  In  order  to  conduct  this 
lab  VMware  Workstation  must  be  installed.  This  lab  scenario  is  using  a 
Windows  7  operating  system 

(5)  Lab  Setup:  Malware  will  be  executed  in  the  virtual  environment.  The 
malware  is  downloaded  from  the  EC-Council  CEHV8  Module  07  DVD 
located  in  the  Viruses  and  Worms  folder.  Processes  and  services  from  the 
two  last  weeks  of  the  computer’s  operations  will  be  saved  inside  process 
explorer.  Once  the  instructor  has  sufficient  processes  and  services  in  the 
tool  and  the  malware  has  been  executed  the  instructor  will  clone  the 
VMware  Workstation  lab  environment  and  name  it  Lab  4  for  future 
student  use. 

(6)  Lab  Write  Up  and  Analysis: 

(i)  Title:  Process  and  Service  Monitoring 

(ii)  Introduction:  The  purpose  of  the  lab  is  to  teach  the  student  how  to 
operate  and  decipher  processes  and  services  using  process  explorer. 
Sometimes  it  can  be  very  difficult  to  determine  if  a  service  or  process 
connection  is  malicious  or  not,  because  many  attackers  are  good  at 
hiding  malicious  processes  and  services  in  plain  sight.  In  order  to 
detect  malicious  services  and  processes  network  defenders  must 
constantly  monitor  them  with  various  tools. 

(iii)  Tools:  Process  Explorer  monitors  and  displays  processes  in  a  tree 
format  that  clearly  shows  the  parent  and  child  relationships  among  the 
said  processes.  In  addition  to  the  formatting,  further  organization  and 
clarity  of  function  is  provided  through  the  use  of  color-coded 
displays.  New  processes — coded  in  green — tend  to  be  the  primary 
source  for  initial  investigation  (Sikorski  &  Honig,  2012).  This  is  all 
depicted  in  Figure  15. 

(iv)  Results:  Provide  screen  shots  with  a  brief  description  that  convey 
pertinent  indicators  of  compromise. 


52 


Figure  15.  Process  Explorer 


S 


3 


Firefox.exe  and  Tcpview.exe  do  not  have  a  company  name  description.  Malware  authors 
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frequently  forget  to  add  them  when  constructing  malware. 

E.  SCENARIO  5— TASK  SCHEDULER  ANALYSIS 

(1)  Target  Time  to  Complete:  30  minutes 

(2)  Lab  Description:  Investigate  places  within  a  computer  that  maybe  used  to 
automatically  execute  programs  at  a  specific  date  and  time  and  where 
these  executables  are  stored.  Screen  shot  suspicious  tasks  and/or  locations 
where  the  binaries  are  stored  for  the  lab  write  up. 

(3)  Expected  Knowledge,  Skills  and  Abilities  to  Complete:  The  student 
must  know  where  the  Scheduled  Task  Manager  can  be  found  and  that  it 
can  be  used  to  execute  malware.  Also,  only  an  administrator  can  schedule 
a  task.  The  administrator  account  for  this  machine  is  Matthew. 

(4)  Source  YM  and  System  Requirements  to  Run:  In  order  to  conduct  this 
lab  VMware  Workstation  must  be  installed.  This  lab  scenario  uses  the 
Windows  7  operating  system 

(5)  Lab  Setup:  Malware  will  be  downloaded  into  the  Windows  Task 
Scheduler.  The  malware  is  downloaded  from  the  EC-Council  CEHV8 
Module  07  DVD  located  in  the  Viruses  and  Worms  folder.  The  malware 
must  be  downloaded  into  the  scheduler  with  an  account  other  than 
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Matthew.  Hundreds  of  good  scheduled  tasks  will  be  placed  in  the 
scheduler  to  provide  complexity  for  the  lab.  After  the  instructor  places  the 
good  tasks  and  malware  into  the  scheduler  the  instructor  will  then  clone 
the  VMware  Workstation  lab  environment  and  name  it  Lab  5  for  future 
student  use. 

(6)  Lab  Write  Up  and  Analysis 

(i)  Title:  Task  Scheduler  Analysis 

(ii)  Introduction:  The  purpose  of  the  lab  is  to  teach  the  student  how  to 
inspect  the  Task  Scheduler  and  spot  malicious  scheduled  tasks. 
Sometimes  it  can  be  very  difficult  to  determine  if  a  task  is  malicious 
or  not  because  many  attackers  are  good  at  hiding  in  plain  sight. 

(iii)  Tools:  “The  Windows  Task  Scheduler  provides  the  ability  to 
automatically  execute  programs  at  a  specific  date  and  time  or  on  a 
recurring  basis”  (Luttgens  et  al.,  2014,  p.305).  This  can  be  seen  in 
Figures  16  and  17. 

(iv)  Results:  Provide  screen  shots  with  a  brief  description  that  convey 
pertinent  indicators  of  compromise. 
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Figure  16.  NortonsUpdate 
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When  you  create  a  task,  you  must  specify  the  action  that  will  occur  when  your  task  starts. 
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This  is  a  common  place  where  attackers  place  malicious  items  if  they  only  have 

command  shell  access. 
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Figure  17.  Author’s  Username  David 
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David  is  not  the  authorized  administrator  account. 


(3  Task  Scheduler  (Local) 

5  Task  Scheduler  Librar 


Name  Status  Triggers  Next  Run  Time  Last  Run  Time  La: 
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Security  options 

When  running  the  task  use  the  following  user  account: 

SYSTEM 

Run  only  when  user  is  logged  on 
®  Run  whether  user  is  logged  on  or  not 

□  Do  not  store  password.  The  task  will  only  have  access  to  local  computer  resources. 
[3  Run  with  highest  privileges 


Change  User  or  Group...  | 
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F.  SCENARIO  6— EXECUTABLE  ANALYSIS 

(1)  Target  Time  to  Complete:  45  minutes 

(2)  Lab  Description:  Use  PEview  to  investigate  200  executables  to  determine 
if  they  contain  malware.  Suspicious  events  are  captured  using  screen  shots 
for  the  lab  write  up. 

(3)  Expected  Knowledge,  Skills  and  Abilities  to  Complete:  The  student 
must  know  that  malware  utilizes  thread  local  storage  callbacks,  which  is 
used  by  malware  to  execute  its  code.  The  student  must  also  know  that  the 
TLS  table  can  be  found  in  the  IMAGE_OPTIONAL_HEADER,  which  is 
found  under  the  IMAGE_NT_HEADERS  using  the  PEview  tool.  TLS 
callbacks  are  usually  not  used  by  applications  that  do  not  contain  malware 
(Sikorski  &  Honig,  2012) 

(4)  Source  YM  and  System  Requirements  to  Run:  In  order  to  conduct  this 
lab  VMware  Workstation  must  be  installed.  This  lab  scenario  uses  the 
Windows  7  operating  system. 

(5)  Lab  Setup:  A  malware  executable  will  be  placed  into  a  folder  on  the 
desktop  with  199  other  non-malicious  executables.  The  malware  is 
downloaded  from  the  viruses  and  worms  folder  on  the  EC-Council 
CEHV8  Module  07  DVD.  Once  the  instructor  adds  the  199  non  malicious 
executables  and  the  executable  with  malware  the  instructor  will  then  clone 
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the  VMware  Workstation  lab  environment  and  name  it  Lab  6  for  future 
student  use. 


(6)  Lab  Write  Up  and  Analysis 

(i)  Title:  Executable  Analysis 

(ii)  Introduction:  The  purpose  of  the  lab  is  to  teach  the  student  how  to 
operate  and  determine  if  an  executable  is  malicious  using  PEview. 
Sometimes  it  can  be  very  difficult  to  determine  if  an  executable  is 
malicious  or  not,  because  many  attackers  are  good  at  hiding  malicious 
executables  in  plain  sight 

(iii)  Tools:  The  Portable  Executable  (PE)  View  is  a  tool  for  viewing  the 
PE  file  structure.  It  allows  the  user  to  view  header  information, 
individual  sections,  as  well  as  import  and  export  tables  of  functions 
operating  on  the  system.  Through  the  use  of  PEView,  thread  local 
storage  (TLS)  callbacks  can  be  effectively  utilized  (Sikorski  &  Honig, 
2012).  The  executable  is  displayed  in  Figure  18  and  its  referencing 
the  TLS  callback  is  shown  in  Figure  19. 

(iv)  Results:  Provide  screen  shots  with  a  brief  description  that  convey 
pertinent  indicators  of  compromise. 


Figure  18.  View  of  the  “Blem”  Executable 
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Figure  19.  Blem.exe  with  a  TLS  Table  in  the  Image  Header 


JP  PEview  -  C:\Users\Matthew\Desktop\blem.exe 


m 


File  View  Go  Help 

£1  O  O  O  ©  Ida  a  IHm  a 


The  TLS  Table  indicates  that  blem.exe  is  potentially  malware. 


SCENARIO  7— REGISTRY  ANALYSIS 


(1)  Target  Time  to  Complete:  60  minutes 

(2)  Lab  Description:  Use  Regshot  to  complete  a  daily  scan  of  the  Registry. 
Screen  shot  anything  suspicious  for  the  lab  write  up. 

(3)  Expected  Knowledge,  Skills  and  Abilities  to  Complete:  The  student  will 
need  to  know  the  impossibility  of  going  through  the  Registry  line  item  by 
line  item  and  how  to  use  the  Regshot  tool.  A  Regshot  image  is  taken  every 
day  at  a  specific  time  and  is  compared  to  the  previous  day’s  image  to 
check  for  potential  malicious  content.  The  student  must  know  how  to  spot 
potential  malicious  items  on  the  output  comparing  the  two  snapshots. 

(4)  Source  VM  and  System  Requirements  to  Run:  In  order  to  conduct  this 
lab  VMware  Workstation  must  be  installed.  This  lab  scenario  uses  the 
Windows  7  operating  system. 

(5)  Lab  Setup:  Malware  will  be  executed  in  the  virtual  environment.  The 
malware  is  downloaded  from  the  EC-council  CEHV8  Module  07  DVD 
located  in  the  Viruses  and  Worms  folder.  The  instructor  must  take  a 
snapshot  of  the  Registry  prior  to  the  execution  of  the  malware. 
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After  the  instructor  takes  the  snapshot  and  executes  the  malware  the 
instructor  will  then  clone  the  VMware  Workstation  lab  environment  and 
name  it  Lab  7  for  future  student  use. 

(6)  Lab  Write  Up  and  Analysis 

(i)  Title:  Registry  Analysis 

(ii)  Introduction:  The  purpose  of  the  lab  is  to  teach  the  student  how  to 
operate  regshot  and  determine  if  anything  malicious  is  hiding  in  the 
Registry.  This  is  extremely  difficult  because  the  Registry  has  many 
files  and  it  is  constantly  changing  with  each  action  conducted  on  the 
machine.  In  order  to  detect  malicious  items  in  the  Registry  network 
defenders  must  be  constantly  monitoring  it  with  various  tools. 

(iii)  Tools:  Regshot  allows  for  Registry  comparison  by  taking  snapshots 
of  a  pre-infected  and  post-infected  system  as  seen  in  Figure  20.  This 
allows  the  Incident  Response  team  to  identify  changes  made  to  the 
system  by  the  malware  as  shown  in  Figure  21.  Unfortunately,  the 
results  will  often  require  plenty  of  patient  scanning  to  decipher  where 
the  pertinent  information  is  (displayed  in  Figure  22). 

(iv)  Results:  Provide  screen  shots  with  a  brief  description  that  convey 
pertinent  indicators  of  compromise. 


Figure  20.  First  Registry  Snapshot 
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Figure  21 .  Second  Registry  Snapshot 
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Figure  22.  MUICache  Display 
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MUICache  signifies  possible  malware.  When  the  program  is  investigated  that  generated 
the  MUICache  key  more  often  than  not,  it  can  be  identified  as  malware  (Carvey,  2014). 
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VI.  CONCLUSIONS  AND  FUTURE  WORK 


Cyber  incident  response  incorporates  all  knowledge,  skills,  techniques,  and  tools 
used  to  prevent  and  detect  malicious  activity,  as  well  as  recover  a  corrupted  system.  The 
information  provided  here  promotes  the  use  of  the  virtual  machines  in  incident  response 
education.  While  incident  response  education  can  be  delivered  via  lectures  and  reading,  a 
way  to  imbue  the  incident  responder  with  greater  familiarity  and  confidence  in  the 
material  is  to  provide  realistic  scenarios  for  training  purposes.  The  best  way  to 
accomplish  this  is  through  the  use  of  VMs. 

A.  CONCLUSIONS 

Incident  response  is  an  iterative  process.  This  is  to  say  the  process  entails  a 
continuous  cycling  effort  to:  establish  defenses,  detect,  identify  and  fix  problems,  and  then 
learn  from  the  experience  in  order  to  improve  the  process  prior  to  the  next  incident.  The 
technical  terms  used  to  explain  these  phases  are  Preparation,  Identification,  Containment, 
Eradication,  Recovery,  and  Lessons  Learned.  The  U.S.  Navy,  like  other  organizations,  is 
highly  dependent  upon  information  systems  and  networks  to  conduct  its  various  missions. 
Thus,  it  is  important  to  ensure  better  preparation  for  incident  handling,  by  improving  the 
education  of  Navy  personnel  most  directly  relied  upon  to  provide  this  vital  service. 

A  way  to  learn  how  to  effectively  defend  a  system  is  through  the  use  of  exercises 
hosted  on  virtual  machines  (VMs).  Chapter  II  covered  the  concept  of  VM  and  the  many 
benefits  of  using  them  in  incident  response  education.  VMs  can  be  used  to  provide  students 
with  hands-on  experience  with  the  types  of  attacks  perpetrators  use,  as  well  as  a  way  of 
directly  interacting  with  and  investigating  them.  A  VM  is  self-contained  and  portable, 
which  means  it  can  be  delivered  via  a  drop  box  or  flash  drive  without  risk  of  harming  the 
actual  machine  it  is  ultimately  to  be  run  (“played”)  on.  Should  a  student  inadvertently  make 
a  mistake  on  their  VM,  they  can  revert  (or  “renew”)  it  back  to  its  state  prior  to  the  mistake 
so  long  as  snap  shots  have  been  taken  throughout  the  activity  conducted.  This  affords  a 
more  risk-free  learning  environment  in  which  to  practice  and  learn.  VMs,  thus,  are 
convenient,  low-risk  as  well  as  cost-effective  for  incident  response  training.  They  also 
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provide  a  convenient  means  with  which  to  capture  intentionally  pre-infected  systems  that 
can  then  be  used  for  incident  response  education. 

Another  aspect  of  good  incident  response  training  is  the  ability  to  isolate  prominent 
IOCs  (indicators  of  compromise).  Chapter  III  enumerated  several  prominent  system 
artifacts  that  would  serve  as  logical  starting  points  when  performing  a  live  incident 
response.  These  include  the  events,  and  various  residual  data  that  would  (should)  indicate 
to  the  student  that  an  incident  is  likely  to  have  occurred.  Because  the  majority  of  Naval 
systems  use  the  Windows  Operating  System  (WOS),  it  was  the  system  chosen  for  the 
exercises  described  in  this  study.  The  WinOS  has  many  components  that  can  potentially 
capture/indicate/reveal  IOCs.  The  Registry,  processes,  certain  files,  network  connections, 
tasks,  accounts,  logs,  and  memory  and  disk  information  all  provide  system  artifacts  that  can 
be  investigated  for  signs  of  infection/exploitation.  Thorough  knowledge  of  these  aspects  of 
the  WinOS  lends  insight  into  what  is  and  is  not  functioning  normally,  as  well  as  pointing 
the  investigation  to  other  likely  indicators  and  evidence. 

In  addition  to  the  operating  system,  network  services  and  applications  are  areas  that 
can  also  be  mined  for  potential  IOCs.  Commonly  targeted  services  are  DHCP,  DNS,  Web, 
and  email.  These  are  often  taken  advantage  of  by  hackers  through  many  different  tactics.  It 
is  equally  important  that  an  incident  responder  know  the  intricacies  of  these  items  and 
where  the  “weaknesses”  lie,  as  is  having  a  broad  understanding  of  the  host  operating 
system  that  they  run  on. 

There  are  numerous  investigative  tools  that  can  be  utilized  in  support  of  an  incident 
investigation.  Rather  than  attempt  to  cover  all  of  them,  this  study  focused  on  those  that  are 
most  prominent  (i.e.,  frequently  used)  in  the  area  of  incident  response.  These  consist  of 
dedicated  add-on  utilities,  as  well  as  OS-native  command  line  programs.  Some  dedicated 
utilities  often  used  are  the  Quick  Checksum  Verifyer,  PEview,  Process  Explorer, 
TCPView,  and  Regshot.  Some  common  OS-native  command  line  tools  and  capabilities 
include  netstat  event  viewer,  viewing  running  processes  and  services,  and  verifying  system 
file  integrity  checksums.  All  these  contribute  to  additional  system  IOC  examination. 

Incident  response  differs  from  digital  forensics  in  that  an  incident  responder  can  be 

likened  to  a  medical  first  responder  (paramedic),  whereas  a  forensics  expert  would  be 
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comparable  to  a  surgeon.  An  incident  responder  is  intended  to  provide  quick  and 
immediate  assistance  to  get  a  system  back  to  proper  functioning  order  (breathing  restored 
and  bleeding  stopped  by  paramedic);  whereas  a  forensics  expert  has  the  more  sophisticated 
knowledge  and  tools  needed  to  dig  deeper  into  the  root  cause(s)  of  an  incident  (treatment  of 
occluded  artery  by  surgeon).  Because  of  the  heavy  reliance  on  technology  by  the  Navy,  it  is 
imperative  that  a  robust  incident  response  capability  be  maintained.  The  use  of  virtual 
machines  in  this  capacity  can  prove  very  valuable.  Virtual  machines  provide  a  “risk-free” 
environment  for  students  to  manipulate  and  interact  with  key  investigative  tools  in  order  to 
identify,  scope,  contain  and  perhaps  eliminate  system  exploits. 

In  furtherance  of  the  above  articulated  goal  of  advancing  incident  response  teaching 
via  pre-infected  VMs,  seven  compromised  system  “scenarios”  were  created  that  entailed 
analysis  of  the  principal  first  responder  WinOS  artifacts  (PUFNTAL);  each  captured  in  a 
separate  VM.  Through  generating  these  scenarios  and  the  research  conducted  here,  we  have 
made  informed  decisions  regarding  which  of  the  many  potential  “attack  craft”  artifacts 
should  be  represented  in  this  set  of  compromised  systems.  The  scenarios  presented  here 
provide  students  with  the  opportunity  to  apply  their  knowledge  of  incident  response  tools, 
IOCs,  and  methodologies,  as  they  go  about  using  tools,  knowledge  and  methodology  to 
identify  the  IOCs  in  each  scenario. 

B.  FUTURE  WORK 

The  idea  described  in  this  study  was  fairly  narrow  in  scope:  identify  the  dominant 
WinOS  artifacts  used  in  incident  response  investigation,  capture  them  in  separate  scenario- 
based  pre-infected  VMs,  then  discuss  the  tools  useful  in  conducting  such  investigations. 
This  scope  could  be  greatly  widened  by  developing  additional  incident  response  VM 
scenarios.  Likely  candidates  for  additional  scenarios  include:  a)  examining  different  OSs, 
b)  adding  additional  artifact  types  (e.g.,  network  traffic  and  firewall  logs),  c)  creating 
hybrid  incident  scenarios  that  require  the  investigator  to  correlate  several  artifact  types,  and 
d)  adding  additional  analysis  tools. 

Gone  are  the  days  of  Windows  reigning  as  the  champion  (and  pretty  much  sole)  OS 
used  by  the  masses.  While  the  majority  still  utilize  Windows  and  various  versions  of  it, 
today  there  are  more  options.  Ubuntu,  Linux  Mint,  Macintosh  OSX,  Android  and  Fedora 
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are  all  alternatives  to  the  dominant  Windows  OS.  Additional  research  can  be  conducted  as 
related  to  the  information  provided  here  to  this  end.  Separate,  dedicated,  VMs  can  be  set  up 
that  address  these  other  alternatives,  allowing  the  individual  to  extend  their  knowledge  of 
incident  response  as  it  pertains  to  an  OS  other  than  Windows.  In  addition,  because  many 
servers  are  UNIX/Linux  based  they  are  often  a  target  for  malicious  attacks.  The  research 
could  be  broadened  to  take  this  into  account 

More  artifact  types  can  be  examined.  The  Windows  Registry  keys  and  values  and 
DNS  queries  were  discussed  here.  However,  others  such  as  the  persistence  mechanism — 
which  allows  malware  to  survive  reboots  and  logins — specifically  could  be  mined  for 
future  work.  In  addition,  artifacts  from  Skype,  Facebook  chat,  and  other  instant  messaging 
services  may  be  further  researched.  These  items  are  specifically  interesting  because  they 
are  commonly  used  by  Naval  personnel  for  communication  purposes  as  they  are  frequently 
away  from  their  families. 

Only  a  few  types  of  incidents  have  been  delved  into  here.  The  idea  was  to  focus  on 
those  that  are  most  common  so  as  to  concentrate  the  type  of  education  provided.  This  being 
stated,  with  time  comes  evolution  of  attackers’  methods.  Because  of  this,  the  kinds  of 
incidents  to  experiment  with  are  many.  An  extension  of  the  work  submitted  here  would  be 
to  provide  alternate  incidents  for  examination. 

There  is  much  that  can  be  done  to  expand  upon  the  ideas  addressed  here.  The  use  of 
VM  in  incident  response  promises  to  be  extremely  beneficial  to  students  for  training 
purposes  and  testing  the  effectiveness  of  these  scenarios  will  exemplify  this.  It  not  only 
provides  the  opportunity  to  make  the  best  use  of  their  knowledge  in  a  hands-on  yet 
controlled  environment;  but  it  also  allows  for  experimentation  with  multiple  types  and 
severities  of  incidents.  The  implication  of  the  use  of  VMs  as  a  source  of  education  needs  to 
be  established  as  criteria  for  graduate  work  as  well  as  incident  response  training  throughout 
the  Navy. 
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